---
id: "bug-1793"
status: "open"
status_updated: "2026-09-24"
status_note: "xce_test join maxswap/maxtmp defaults are stale byte values (join_worker_args.c)"
component: "controller"
severity: "unknown"
timestamp: "2026-09-09T16:24:19Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/controller/testsuite/join_worker_args.c (join_worker_parse_attrs", "hostattrs_t default initialization)"]
tags: ["controller", "testsuite", "xce_test", "cmd_join_worker", "stale-default", "units", "deferred"]
related: ["bug-1557"]
legacy: true
---

# bug-1793: xce_test's worker->join command's maxswap (1024) and maxtmp (2048) defaults have the same…

## Description
xce_test's worker->join command's maxswap (1024) and maxtmp (2048) defaults have the same stale-MB-scale bug as bug-1557's maxmem -- discovered while fixing bug-1557 (xce-test-cli-ux task 2.6)

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
Same root cause as bug-1557: maxswap/maxtmp were reasonable defaults (1KB/2KB) back when these fields were a smaller unit, but an earlier session converted maxswap/maxtmp to bytes-canonical (confirmed via resources.yaml 'max swap/tmp disk space in bytes' and hardware_monitor.c's raw-byte sysinfo()/statvfs() computations) without updating this test-tool default. 1024 bytes of swap / 2048 bytes of tmp are just as nonsensical as the old maxmem=64 bytes.

## Fix
NOT FIXED -- deliberately deferred (xce-test-cli-ux task 2.6). USAGE_JOIN_WORKER's help text currently documents these exact stale values accurately, so fixing only the code without also fixing the docs would create a new code/docs mismatch outside task 2.6's Requirement-12.1-scoped mandate (which covers maxmem only). Recommended: a coordinated fix changing both defaults (e.g. maxswap to a byte-scale value matching typical swap sizing, maxtmp similarly) AND USAGE_JOIN_WORKER's documented defaults, together. A regression test (test_join_worker_sibling_defaults_unchanged in test_join_worker_args.c) currently locks in today's stale values specifically so a future fix here doesn't collide with bug-1557's maxmem-specific test assertions -- update/remove that test's maxswap/maxtmp assertions when this bug is actually fixed.

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1557