A city 311 routing script declares a queue name at module scope, then a helper function assigns the same name to a temporary overflow queue. Overnight tickets land in the overflow queue citywide. What change keeps the helper from overwriting the citywide ticket queue name?
Select an answer to reveal the explanation.
Short Explanation
Think of the citywide queue name like the main street address on City Hall—helpers shouldn't paint over it with a side-door label. Give the helper its own local variable so the module-level queue name stays put for overnight routing.
Full Explanation
In municipal 311 routing scripts, names resolve according to scope rules: a binding declared at module scope is shared across callers unless a nested scope introduces the same identifier and shadows or reassigns it. When a helper function assigns the citywide ticket queue name to a temporary overflow queue, that assignment can overwrite or shadow the module-level value so overnight tickets divert citywide into overflow. The correct remediation is to leave the citywide queue name outside the helper and introduce a differently named local variable for the overflow target. Distinct identifiers keep the shared routing destination stable while still allowing the helper to reference a temporary queue for its own logic. Moving the citywide name into a mutable global that every helper reassigns amplifies the same defect: every call site can still clobber the production queue, and the blast radius grows rather than shrinks. Deleting the module-level queue name so each call invents a fresh string literal removes the single source of truth operators rely on for citywide routing and forces fragile duplication of literals. Passing the overflow queue through an environment variable while ignoring function scope does not fix the identifier collision inside the helper; environment configuration is orthogonal to whether the helper reassigns the shared name. Exam caveat: languages differ on whether assignment in a nested function updates an outer binding or creates a local, and some require explicit nonlocal or global declarations—read the language rules, but the operational principle is the same: do not reuse the production queue identifier for temporary overflow. Operational check: after the change, invoke the helper under a test load, confirm the module-level queue name still equals the citywide ticket queue, verify overflow traffic uses only the local name, and spot-check overnight ticket destination metrics so tickets do not land in overflow by accident.