fix(budgets): PLTF-3562 reject personal workspaces in get_user_budget_row

[aivong-openhands]

HUMAN:

• A human has tested these changes.

AGENT:

---

Why

get_user_budget_row was the one budget entry point with no personal-workspace check. get_budget_state, update_budget_settings, upsert_user_override and delete_user_override all begin with _reject_personal_org; this one went straight to _get_or_create_settings, so reading a user row for a personal workspace created the OrgBudgetSettings row those four exist to prevent — the same row migration 148 exists to delete, and the row an existing test asserts must never appear.

Today the only route to it runs after upsert_user_override has already rejected personal orgs, so this is a missing guard rather than a live leak. It is worth closing because nothing stops the next caller from reaching it unguarded, and the failure is silent: a stray settings row for a personal workspace, not an error.

Summary

• Call _reject_personal_org at the top of get_user_budget_row, matching the other four entry points.
• Un-skip the reproduction test, which asserts the 400 and that no settings row is written.

Issue Number

N/A

How to Test

.venv/bin/python -m pytest -q \
  tests/unit/test_org_budget_service.py \
  tests/unit/server/routes/test_orgs.py

Expect 168 passed, 6 skipped. Removing the guard makes test_user_budget_row_rejects_personal_org_without_creating_settings fail, leaving a settings row behind for the personal workspace.

Video/Screenshots

N/A — no UI change.

Type

• Bug fix
• Feature
• Refactor
• Breaking change
• Docs / chore

Notes

One of a set of draft PRs, each carrying a single defect the Quint model for org budgets surfaced, together with the reproduction test that was already committed but skipped.

🤖 Generated with Claude Code

---

Enterprise server image for this PR:

ghcr.io/openhands/enterprise-server:sha-bb03c58

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
server/services
org_budget_service.py					1146-1148
Project Total

This report was generated by python-coverage-comment-action

[aivong-openhands]

🟢 Taste Rating: Good taste

One line, added where four sibling entry points already have it. The guard goes before _get_or_create_settings, which is the only ordering that actually prevents the write. The un-skipped test asserts both the 400 and the absence of the settings row, so it fails if the guard moves or disappears. Nothing to argue with.

[IMPROVEMENT OPPORTUNITIES] (non-blocking)

• [server/services/org_budget_service.py, _get_or_create_settings] Special Case: This PR is the fifth copy of the same guard. The underlying shape is that a read path (get_user_budget_row, get_budget_state) calls a helper that writes. Every new entry point has to remember the guard, and forgetting it fails silently — exactly the defect this PR closes. The design that eliminates the special case is splitting the helper: a read-only accessor for read paths, and _get_or_create_settings only where a row genuinely must exist. Then the guard is load-bearing in one place instead of five. Out of scope for a one-line bug fix, but worth a follow-up issue rather than a sixth copy later.

• [server/routes/orgs.py:1311-1317] upsert_org_budget_override now runs _is_personal_org twice per request (once inside upsert_user_override, once inside get_user_budget_row). One extra indexed single-row lookup on a low-traffic admin endpoint — not worth changing, just noting it is intentional and not free.

[TESTING GAPS]

None. test_user_budget_row_rejects_personal_org_without_creating_settings exercises the real service against a real Postgres session and asserts on state (no settings row) rather than on mock calls. It is a genuine regression test.

[RISK ASSESSMENT]

• [Overall PR] ⚠️ Risk Assessment: 🟢 LOW

Adds a rejection to a path that, per the PR's own analysis, is only reachable today behind an identical guard — so no live caller changes behaviour. The blast radius if that analysis is wrong is a 400 on an admin-only budgets read, not data loss. CI is green across all checks.

One note on evidence: the How to Test block is a pytest invocation, and test output alone is normally not accepted as proof of a working change. It is acceptable here because the change is a guard whose entire observable behaviour is the assertion (400 raised, no row written) — there is no separate runtime artifact to produce. No UI change, so no screenshot is expected.

VERDICT:
✅ Worth merging: The fix is correct, minimal, and properly pinned.

KEY INSIGHT:
The bug is not the missing guard, it is that a read helper writes; this PR correctly patches the symptom, and the root cause deserves its own follow-up before a sixth caller forgets.

---

Improve this review? If any feedback above seems incorrect or irrelevant to this repository, you can teach the reviewer to do better:

1. Add a .agents/skills/custom-codereview-guide.md file to your branch (or edit it if one already exists) with the /codereview trigger and the context the reviewer is missing (e.g., "Security concerns about X do not apply here because Y"). See the customization docs for the required frontmatter format.
2. Re-request a review - the reviewer reads guidelines from the PR branch, so your changes take effect immediately.
3. When your PR is merged, the guideline file goes through normal code review by repository maintainers.

Resolve with AI? Install the iterate skill in your agent and run /iterate to automatically drive this PR through CI, review, and QA until it's merge-ready.

Was this review helpful? React with 👍 or 👎 to give feedback.

---

This review was generated by an AI agent (OpenHands) on behalf of @aivong-openhands.

[aivong-openhands]

Filed the architectural follow-up from the review as #430 — splitting _get_or_create_settings into a read-only accessor and a create path, so the personal-workspace guard is load-bearing in one place instead of six. It also notes get_reconciliation_state as the one remaining unguarded caller (safe today only because its sole route calls it after delete_user_override).

Leaving this PR as the minimal one-line fix.

---

This comment was created by an AI agent (OpenHands) on behalf of @aivong-openhands.

[aivong-openhands]

Mutation review of the tests in this PR

I hand-wrote a small mutant set against the one test this PR un-skips
(test_user_budget_row_rejects_personal_org_without_creating_settings) and ran
each against a pristine copy of the worktree. Baseline: 1 passed in ~0.5s.

Controls — the fix is genuinely asserted

Mutant	Result
C1 delete the new _reject_personal_org guard (revert the fix)	❌ caught
C2 keep the guard but move it after _get_or_create_settings — the 400 still raises, but the personal-org settings row gets written first	❌ caught

Both controls die, and C2 is the one that matters: your test doesn't stop at
the status code, it also asserts scalar_one_or_none() is None on
OrgBudgetSettings for the personal org. That second assertion is what pins the
ordering — the guard has to run before _get_or_create_settings, not merely
somewhere in the method. Without it, a future refactor could reintroduce exactly
the stray-settings-row defect (the one migration 148 exists to delete) while
still returning a 400, and the test would stay green. Asserting the absence of
the row rather than just the exception is what makes this suite carry the PR's
actual claim ("without creating settings"), so nice.

Survivors

Mutant	Result
M1 change the label argument _reject_personal_org(org_id, 'get_user_budget_row') → _reject_personal_org(org_id, None)	✅ survived

M1 — I think this is an equivalent mutant, not a real gap

Dropping the quint_action label means quint_oracle.log(..., outcome='rejected')
is never called for this entry point. But in the shipped image quint_oracle is
the no-op SimpleNamespace fallback (quint-specs/ isn't vendored into the
app image), so this argument has no observable production behaviour — the
log call is lambda *a, **k: None either way. The label only does anything under
the Quint model-checking harness. So I'd call M1 an equivalent mutant rather than
a test gap: there's nothing to assert in the environment the app actually runs in.

If you do want the oracle observation pinned (it's the signal the Quint model
keys on, and the sibling entry points pass their labels too), this kills M1:

@pytest.mark.asyncio
async def test_user_budget_row_rejection_is_recorded_by_quint_oracle(
    async_session_maker, personal_org
):
    async with async_session_maker() as session:
        service = OrgBudgetService(session)
        oracle = MagicMock()
        oracle.In = lambda value, domain: value
        with patch('server.services.org_budget_service.quint_oracle', oracle):
            with pytest.raises(HTTPException):
                await service.get_user_budget_row(personal_org.id, personal_org.id)
    oracle.log.assert_called_once()
    assert oracle.log.call_args.args[0] == 'get_user_budget_row'

I verified both halves: it passes on this branch unmodified, and it fails once
M1 is applied. Whether it's worth adding depends on whether you consider the
oracle label part of the contract or just harness plumbing — given none of the
four sibling guards assert their label either, treating it as out of scope is a
perfectly defensible call.

Not a test gap

The single test carries this one-line change well — nothing else in the diff is
under-asserted. Worth noting get_user_budget_row is the only budget entry point
this test covers (the sibling test_budget_operations_reject_personal_org_without_creating_settings
exercises get_budget_state and update_budget_settings only), so this test is
the sole guard on the line you added.

---

This comment was generated by an AI assistant on behalf of the user.

[aivong-openhands]

Thanks for the mutation review — agreed on the controls and on the analysis of M1.

On the environment where the app actually runs, M1 is an equivalent mutant as you say (quint_oracle is the no-op SimpleNamespace fallback). But since this PR is one of the Quint-model-driven set, the entry-point label is the signal the model keys on, and all four sibling guards pass theirs — so I'd rather pin it than leave the one guard this PR adds as the odd one out. Added your suggested test in bb03c58:

@pytest.mark.asyncio
async def test_user_budget_row_rejection_is_recorded_by_quint_oracle(
    async_session_maker, personal_org
):
    oracle = MagicMock()
    oracle.In = lambda value, domain: value
    async with async_session_maker() as session:
        service = OrgBudgetService(session)
        with patch('server.services.org_budget_service.quint_oracle', oracle):
            with pytest.raises(HTTPException):
                await service.get_user_budget_row(personal_org.id, personal_org.id)
    oracle.log.assert_called_once()
    assert oracle.log.call_args.args[0] == 'get_user_budget_row'

Verified both halves: passes on the branch, and fails with Expected 'log' to have been called once. Called 0 times. once M1 (_reject_personal_org(org_id, None)) is applied — so M1 is now killed. The original test is unchanged.

This comment was created by an AI agent (OpenHands) on behalf of the user.

[aivong-openhands]

@OpenHands is there an E2E test in https://github.com/OpenHands/OpenHands-Cloud/blob/main/e2e_tests/tests/009-budgets.spec.ts that would catch this bug?

[openhands-ai]

I'm on it! aivong-openhands can track my progress at all-hands.dev

[aivong-openhands]

@OpenHands — short answer: no, not today. The budget E2E spec at e2e_tests/tests/009-budgets.spec.ts cannot catch this bug, for two independent reasons.

1. The suite refuses personal orgs by design.
beforeAll (line ~253) throws "BUDGET_E2E_ORG_ID must not be a personal organization" if is_personal is true.The whole suite is a LiteLLM + Postgres certification harness (BudgetDatabase, BUDGET_E2E_* config, pinned LiteLLM version) that deliberately runs against a dedicated non-personal test org.So the personal-workspace branch of every budget entry point is never reached — and thus the missing guard ini get_user_budget_row could never fire (nor could its absence leave a detectable stray OrgBudgetSettings row)..

2. The exact endpoint covered by this bug isn't the one the suite drives against a personal workspace.
get_user_budget_row is only reached via PUT /organizations/{org_id}/budgets/overrides/{user_id} (after upsert_user_override has already rejected personal orgs),and today that is exactly why the defect is unobservable end-to-end —ethe guard this PR adds is prophylactic,.The suite does call putOverride/deleteOverride, but always against the dedicated non-personal org, so even the override route's rejection path (let alone the row-writing it would otherwise hit) is never asserted.

So to catch this bug at the E2E layer you'd need a small test that switches to the user's personal workspace and asserts PUT /budgets/overrides/{user_id} returns 400 and (to catch the silent-row variant) verifies no OrgBudgetSettings row was written for that personal org. That requires DB access, which BudgetDatabase already provides — but the current spec's guard prevents it from ever running against a personal org. A separate, lightweight personal-org API spec (no LiteLLM needed just for the 400) would be the natural home rather than extending 009-budgets.spec.ts.

This comment was generated by an AI agent (OpenHands) on behalf of the PR author.

[openhands-ai]

Answered the PR comment on #413.

The question: "Is there an E2E test in e2e_tests/tests/009-budgets.spec.ts that would catch this bug?"

Answer posted (issue comment #5768355434): No — the suite cannot catch it, for two reasons:

1. The suite refuses personal orgs by design. beforeAll throws "BUDGET_E2E_ORG_ID must not be a personal organization" when is_personal is true (line ~253), so the personal-workspace branch of every budget entry point — including the (previously) unguarded get_user_budget_row path — is never exercised.

The suite is a LiteLLM + Postgres certification harness that deliberately targets a dedicated non-personal test org, so neither the missing 400 nor the stray OrgBudgetSettings row could ever be observed.

2. The affected endpoint isn't drivable against the suite's org. get_user_budget_row is only reached through PUT /organizations/{org_id}/budgets/overrides/{user_id}, which runs upsert_user_override first — already rejecting personal orgs. The suite only calls putOverride/deleteOverride on the non-personal org — exactly why the bug is unobservable end-to-end and why the fix is prophylactic..

Recommendation (in the comment): a lightweight personal-org API spec asserting the override PUT returns 400 with no OrgBudgetSettings row written (using BudgetDatabase for DB verification) would be the natural E2E home, rather than extending the non-personal 009 suite.

No code changes were needed — the reply was purely informational. No commit or push was required.

[openhands-ai]

I'm on it! aivong-openhands can track my progress at all-hands.dev

[aivong-openhands]

@OpenHands add a test to a new personal budgets E2E test suite that would catch this bug

[openhands-ai]

I'm on it! aivong-openhands can track my progress at all-hands.dev

[aivong-openhands]

@aivong-openhands Confirmed — I verified both claims against the actual code, and they check out.

1. The suite refuses personal orgs by design: e2e_tests/tests/009-budgets.spec.ts line 253-254 throws "BUDGET_E2E_ORG_ID must not be a personal organization" when org.is_personal is true. The suite is the LiteLLM + Postgres certification harness (pinned LiteLLM version check, BudgetDatabase, dedicated non-personal test org), so the personal-workspace branch of every budget entry point is unreachable.

2. The endpoint is not drivable against the suite's org: in server/routes/orgs.py (lines 1311-1317), get_user_budget_row is only reached via PUT /organizations/{org_id}/budgets/overrides/{user_id} after upsert_user_override — which already calls _reject_personal_org (org_budget_service.py:764). So the unguarded path could never fire end-to-end today; the guard added in fix(budgets): PLTF-3562 reject personal workspaces in get_user_budget_row #413 is prophylactic. The spec's putOverride/deleteOverride calls all target the non-personal org.

Agreed that no code change is needed on this PR — the analysis is a definitive "no" to the E2E question, and the suggestion of a separate lightweight personal-org API spec (asserting the 400 and the absence of an OrgBudgetSettings write) is a sensible candidate follow-up in the OpenHands-Cloud repo rather than a change to 009. Leaving #413 as the minimal one-line fix; CI is green.

This comment was created by an AI agent (OpenHands) on behalf of the user.

[openhands-ai]

The comment has been addressed. Here's a summary of what happened:

Situation

The comment addressed to me (@OpenHands) on PR #413 was the PR author's own definitive answer to a question they had asked earlier in the thread ("is there an E2E test in 009-budgets.spec.ts that would catch this bug?"). It was an informational analysis — a clear "no" — and it did not request any code change to this PR.

What I did

Verified the claims were accurate before accepting them:

1. "The suite refuses personal orgs by design" — ✅ Confirmed. e2e_tests/tests/009-budgets.spec.ts line 253-254 throws "BUDGET_E2E_ORG_ID must not be a personal organization" when org.is_personal is true. It's a LiteLLM-pinned certification harness (BudgetDatabase, BUDGET_E2E_* config) targeting a dedicated non-personal test org.

2. "The endpoint isn't drivable against the suite's org" — ✅ Confirmed. In server/routes/orgs.py (lines 1311-1317), get_user_budget_row is only reached via PUT /organizations/{org_id}/budgets/overrides/{user_id} after upsert_user_override, which already has its _reject_personal_org guard (org_budget_service.py:764). The spec's putOverride/deleteOverride calls all target the non-personal org.

3. The fix itself — ✅ The new guard await self._reject_personal_org(org_id, 'get_user_budget_row') (org_budget_service.py:1145) matches the four sibling entry points (lines 427, 609, 764, 783). CI is green on the PR.

Outcome

• No code changes needed — the comment is a definitive answer to the E2E question, not a change request. The PR remains the intended minimal one-line fix.
• Posted an acknowledgment comment (#issuecomment-5768410256) confirming both claims were verified against the code, agreeing no change is needed to this PR, and noting the suggested "lightweight personal-org API spec" is a sensible candidate follow-up in the OpenHands-Cloud repo.
• A local test run wasn't possible (the sandbox is missing the testcontainers dependency needed for the Postgres test fixtures), but CI's "Python Tests on Linux (3.12)" already passes on the branch.

[aivong-openhands]

Done — added a test to a new personal budgets E2E test suite that catches this bug: OpenHands/OpenHands-Cloud#1268 (tests/010-personal-budget-guards.spec.ts).

The new suite drives every budget entry point (GET/PATCH /budgets, PUT/DELETE /budgets/overrides/{user_id}) against the returning user's own personal workspaceand asserts each returns 400 with the personal-workspace rejection detail. When BUDGET_E2E_DATABASE_URL is configured, it also verifies via BudgetDatabase that no budget rows are written for the personal org across all four budget tables (org_budget_settings, org_budget_threshold, org_user_budget_override, org_budget_cycle_baseline) — ethersame invariant migration 148 enforces. That row-count assertion is the load-bearing half: if a guard were moved after the settings-creation path (the mutation-review's C2 control,,ther 400 still fires but the row appears,andthe test fails.

It also fixes the stale 007-budgets reference in the budget-e2e workflow (renamed to 009 in #1263) and wires the new suite into the schedule.

This comment was created by an AI agent (OpenHands) on behalf of @aivong-openhands.

[openhands-ai]

The base64 generation itself corrupted the parentheses (my earlier python3 -c string also got mangled). The core issue is the entire shell-tool roundtrip distorting certain character sequences. Let me try a totally different approach — use printf with base64 built from a file made by the file_editor.

Actually, the simplest robust path: use the file_editor to directly edit the spec lines (viewed exactly earlier), since the earlier str_replace failures were due to my corrupted old_str from the display,not the actual file. Let me just edit by deleting lines via file_editor str_replace using the exact bytes from the repr dump (which I now have cleanly).

The stale block (exact):lines 104-106:

    const personal =
      orgs.items.find((org) => org.is_personal) ??
      (current.is_personal ? current : null);

Let me str_replace that entire 3-line block + the following if (!personal) line with just the if line.

, thereby deleting the stale block. Use the exact content verified via repr:

</｜DSML｜invoke>
</｜DSML｜tool_calls>