Honor accepted-work API limit

[NiXouuuu]

Bounty #799

Source report: #798 (comment)

This PR implements a focused fix for the public account accepted-work API silently ignoring limit query values:

• /api/v1/accounts/{account}/accepted-work?limit=1 now returns one accepted-work row while keeping the summary totals uncapped.
• limit is bounded with the same 1..200 shape used by nearby public list endpoints.
• repeated or non-canonical integer spellings such as limit=01 are rejected before FastAPI coercion.
• existing account normalization and the account page behavior remain unchanged.

Validation:

• uv run --extra dev pytest tests/test_account_routes.py::test_account_accepted_work_api_honors_canonical_limit -q -> 1 passed, 1 existing Starlette/httpx warning.
• uv run --extra dev pytest tests/test_account_routes.py tests/test_serializers.py tests/test_api_mcp.py::test_explorer_links_ledger_proof_and_account tests/test_api_mcp.py::test_account_api_keeps_schema_when_accepted_work_proof_is_malformed -q -> 21 passed, 1 existing Starlette/httpx warning.
• uv run --extra dev ruff check app/accounts.py app/serializers.py tests/test_account_routes.py -> passed.
• uv run --extra dev ruff format --check app/accounts.py app/serializers.py tests/test_account_routes.py -> 3 files already formatted.
• uv run --extra dev mypy app/accounts.py app/serializers.py -> success.
• uv run --extra dev python scripts/docs_smoke.py -> docs smoke ok.
• git diff --check origin/main...HEAD -> clean.
• git merge-tree --write-tree origin/main HEAD -> clean tree 7fb1b2541ddfeb1b3655e87b5f2dd4a4de39f295.

Scope: public account accepted-work row limiting only. No payout execution, treasury mutation, wallet mutation, ledger mutation, admin-token behavior, private data, secrets, bridge/exchange/cash-out behavior, or MRWK price behavior changed.

Summary by CodeRabbit

• New Features
  • Added optional limit query parameter (1–200) to the accepted-work endpoint; requests with non-canonical formatting are rejected with appropriate validation errors.
• Tests
  • Added API tests covering default behavior, valid limits, out-of-range rejections, non-canonical formatting rejection, and repeated-parameter rejection.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 3415d4e8-5644-49f3-896d-462f76be00e6

📥 Commits

Reviewing files that changed from the base of the PR and between 18d1f9c and bd41893.

📒 Files selected for processing (1)

• tests/test_account_routes.py

---

📝 Walkthrough

Walkthrough

Adds an optional limit query parameter (1–200) to the accepted-work endpoint, validates canonical and non-repeated integer formatting, threads limit through the context builder into the serializer, and applies it to the DB query. Tests cover valid, out-of-range, non-canonical, and repeated-parameter cases.

Changes

Accepted-Work Limit Feature

Layer / File(s)	Summary
Query parameter validation imports app/accounts.py	Annotated type and reject_noncanonical_int_query_param are imported to enable canonical integer query parameter validation.
API handler and context builder app/accounts.py	The /api/v1/accounts/{account}/accepted-work endpoint accepts an optional limit query parameter (Query(ge=1, le=200)), rejects repeated/non-canonical values, and forwards limit into account_accepted_work_context (signature now accepts limit).
Query execution with limit app/serializers.py	accepted_work_for_account gains an optional limit parameter and conditionally applies .limit(limit) to the SQLAlchemy query before execution when limit is provided.
Test validation for limit behavior tests/test_account_routes.py	Integration test seeds three accepted-work proofs and verifies default behavior, limit=1, limit=200, out-of-range rejections (0 and 201), non-canonical limit=01 rejection (400), and repeated limit parameters rejection (400).

Possibly related PRs

• ramimbo/mergework#295: Touches the accepted-work account data path and related helpers affecting accepted_work_for_account usage.
• ramimbo/mergework#306: Implemented the base accepted-work endpoint; this PR extends it with limit handling and validation.

🚥 Pre-merge checks | ✅ 6

✅ Passed checks (6 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Honor accepted-work API limit' clearly and concretely names the changed surface—it describes the specific feature (accepted-work API limit support) that is the main focus of the changeset.
Description check	✅ Passed	The description provides all required sections: a concise summary explaining the fix, evidence of the problem addressed with a source link, clear statement of files and surfaces changed, explicit scope boundaries, and comprehensive validation evidence for all listed checks.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Mergework Public Artifact Hygiene	✅ Passed	PR contains no investment claims, price claims, cash-out claims, fabricated payouts, or security details. Changes are limited to query parameter validation for the accepted-work API.
Bounty Pr Focus	✅ Passed	PR does not reference Bounty #N or Refs #N explicitly, so the custom check is not applicable. The changes are focused on accepted-work API limit feature with proper scope, tests, and validation.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[laughlife]

Reviewed current head 18d1f9cb4e8cef56cced09c79ce4952c8a62aae3 as a non-author.

Scope checked:

• app/accounts.py: /api/v1/accounts/{account}/accepted-work now accepts a bounded limit query parameter, rejects repeated limit, rejects non-canonical integer spellings, and passes the parsed limit into account_accepted_work_context().
• app/serializers.py: accepted_work_for_account() now applies the optional limit at the SQL query level before serializing proof-backed rows, so the API does not fetch the full account history when limit=1 is requested.
• tests/test_account_routes.py: covers the production report behavior for the API: full response remains uncapped by default, limit=1 returns one latest row while preserving full summary totals, and limit=01 fails closed.

Local validation on this head:

• uv run --extra dev pytest tests/test_account_routes.py::test_account_accepted_work_api_honors_canonical_limit -q -> 1 passed, 1 existing Starlette/httpx warning.
• uv run --extra dev pytest tests/test_account_routes.py -q -> 8 passed, 1 existing Starlette/httpx warning.
• uv run --extra dev ruff check app/accounts.py app/serializers.py tests/test_account_routes.py -> passed.
• uv run --extra dev ruff format --check app/accounts.py app/serializers.py tests/test_account_routes.py -> 3 files already formatted.
• uv run --extra dev mypy app/accounts.py app/serializers.py -> success.
• uv run --extra dev python scripts/docs_smoke.py -> docs smoke ok.
• git diff --check origin/main...HEAD -> clean.
• git merge-tree origin/main HEAD -> clean tree 7fb1b2541ddfeb1b3655e87b5f2dd4a4de39f295.

This PR is a focused API-path fix. It does not cover the public account page row limit or docs wording that PR #864 covers, while PR #864 does not push the API limit down into the SQL query. Maintainers may want to choose one direction or consolidate the API query-level limit with the broader page/docs coverage. CodeRabbit was still pending at review time and was not counted as completed evidence.

[coderabbitai]

Actionable comments posted: 1

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e6855597-94ad-4dc7-a158-6242b4b2608b

📥 Commits

Reviewing files that changed from the base of the PR and between d4d0e48 and 18d1f9c.

📒 Files selected for processing (3)

• app/accounts.py
• app/serializers.py
• tests/test_account_routes.py

[NiXouuuu]

Follow-up for the CodeRabbit boundary coverage warning.

Added assertions in tests/test_account_routes.py::test_account_accepted_work_api_honors_canonical_limit for:

• limit=200 -> 200 with all available rows
• limit=0 -> 422
• limit=201 -> 422
• repeated limit -> 400 limit must be provided at most once

Local validation on new head bd41893191e954ff6f82d44cc04ffe6633f7c295:

• uv run --extra dev pytest tests/test_account_routes.py::test_account_accepted_work_api_honors_canonical_limit -q -> 1 passed, 1 existing Starlette/httpx warning
• uv run --extra dev pytest tests/test_account_routes.py -q -> 8 passed, 1 existing Starlette/httpx warning
• uv run --extra dev ruff check app/accounts.py app/serializers.py tests/test_account_routes.py -> passed
• uv run --extra dev ruff format --check app/accounts.py app/serializers.py tests/test_account_routes.py -> 3 files already formatted
• uv run --extra dev mypy app/accounts.py app/serializers.py -> success
• uv run --extra dev python scripts/docs_smoke.py -> docs smoke ok
• git diff --check origin/main...HEAD -> clean
• git merge-tree origin/main HEAD -> clean tree 943dd339efbed34059bc019651c54e95b789dbab

[laughlife]

Current-head review for bd41893191e954ff6f82d44cc04ffe6633f7c295.

I rechecked this after the boundary-test update made my earlier review stale. This PR cleanly limits the accepted-work API at query level via accepted_work_for_account(..., limit=...), preserves the default unbounded API shape when limit is omitted, and keeps summary totals based on the full account history while capping only the returned accepted_work rows.

Validation I ran locally:

• uv run --extra dev pytest tests/test_account_routes.py::test_account_accepted_work_api_honors_canonical_limit -q -> 1 passed, 1 existing Starlette/httpx warning.
• uv run --extra dev pytest tests/test_account_routes.py -q -> 8 passed, 1 existing Starlette/httpx warning.
• uv run --extra dev ruff check app/accounts.py app/serializers.py tests/test_account_routes.py -> passed.
• uv run --extra dev ruff format --check app/accounts.py app/serializers.py tests/test_account_routes.py -> passed.
• uv run --extra dev mypy app/accounts.py app/serializers.py -> passed.
• uv run --extra dev python scripts/docs_smoke.py -> passed.
• git diff --check origin/main...HEAD -> clean.
• git merge-tree origin/main HEAD -> clean tree 943dd339efbed34059bc019651c54e95b789dbab.

The hosted Quality/readiness/docs check is successful. CodeRabbit was still pending at review time, so I am not counting that as completed evidence. This overlaps with PR #864 only around the accepted-work limit theme; this version is specifically the API/query-level implementation.

[xiefuzheng713-alt]

Reviewed current head bd41893191e954ff6f82d44cc04ffe6633f7c295 for the accepted-work API limit fix.

Checked changed files:

• app/accounts.py
• app/serializers.py
• tests/test_account_routes.py

What I verified:

• /api/v1/accounts/{account}/accepted-work now accepts an optional bounded limit=1..200 query value.
• Repeated and non-canonical limit values are rejected through the existing query validation helpers.
• account_accepted_work_context() forwards the limit only to the accepted-work row query.
• account_accepted_summary() remains uncapped, so summary totals still describe the full account history.
• accepted_work_for_account() applies SQL-level .limit(limit) only when the caller provides a limit.
• Regression coverage verifies full output when omitted, limit=1 returning the newest row, limit=200, 422 range errors, repeated limit rejection, and limit=01 rejection.

GitHub state checked before review: mergeStateStatus=CLEAN, hosted Quality/readiness/docs/image check passed, and CodeRabbit status passed. I did not see regressions in the touched API behavior.

[tudorian95]

Reviewed current head bd41893191e954ff6f82d44cc04ffe6633f7c295 for Bounty #838.

What I checked:

• Inspected the focused diff in app/accounts.py, app/serializers.py, and tests/test_account_routes.py.
• Confirmed the live production before-state is still reproducible with harmless GETs: GET /api/v1/accounts/github:likeacloud7/accepted-work returned 8 accepted-work rows, and GET /api/v1/accounts/github:likeacloud7/accepted-work?limit=1 also returned 8 rows while preserving summary totals. I also confirmed limit=01 and repeated limit=1&limit=2 currently return HTTP 200 on production.
• In Docker/uv on a fresh checkout of this PR head:
  • uv run --extra dev pytest tests/test_account_routes.py::test_account_accepted_work_api_honors_canonical_limit -q -> 1 passed, 1 existing Starlette/httpx warning.
  • uv run --extra dev pytest tests/test_account_routes.py tests/test_serializers.py tests/test_api_mcp.py::test_explorer_links_ledger_proof_and_account tests/test_api_mcp.py::test_account_api_keeps_schema_when_accepted_work_proof_is_malformed -q -> 21 passed, 1 existing warning.
  • uv run --extra dev ruff check app/accounts.py app/serializers.py tests/test_account_routes.py -> passed.
  • uv run --extra dev ruff format --check app/accounts.py app/serializers.py tests/test_account_routes.py -> passed.
  • uv run --extra dev mypy app/accounts.py app/serializers.py -> success.
  • uv run --extra dev python scripts/docs_smoke.py -> docs smoke ok.
  • git diff --check origin/main...HEAD -> clean.
• git merge-tree --write-tree origin/main HEAD succeeded with tree 943dd339efbed34059bc019651c54e95b789dbab.
• GitHub reports the current head as MERGEABLE.

The implementation limits only the returned accepted-work rows while leaving account summary totals uncapped, which preserves the API shape and expected accounting semantics. I did not find blockers.