asf-tooling commented on issue #785:
URL: 
https://github.com/apache/tooling-trusted-releases/issues/785#issuecomment-4410097509

   <!-- gofannon-issue-triage-bot v2 -->
   
   **Automated triage** — analyzed at `main@2da7807a`
   
   **Type:** `discussion`  •  **Classification:** `no_action`  •  
**Confidence:** `high`  •  ⚠️ **Stale — consider closing**
   **Application domain(s):** `web_api_infrastructure`, `shared_infrastructure`
   
   ### Summary
   Issue #785 originally proposed separating test routes into their own 
blueprint, but @sbp concluded (2026-03-12) that this should NOT be done because 
it would require replicating custom typed decorators with tiny differences that 
could diverge from production code. @dave2wave then renamed the issue to 'Tidy 
test route blueprints' and later asked (2026-03-19) 'Is there anything to do? 
All of the test endpoints use @get.typed or @post.typed.' — implying the work 
is already complete. Code inspection confirms all test routes in both 
atr/get/test.py and atr/post/test.py already use the standard @get.typed and 
@post.typed decorators, matching the desired state.
   
   ### Where this lives in the code today
   
   #### `atr/get/test.py` — `test_empty` (lines 46-52)
   _currently does this_
   Test GET route already uses @get.typed decorator — the standard blueprint 
decorator for type-safe routes.
   
   ```python
   @get.typed
   async def test_empty(_session: web.Public, _test_empty: 
Literal["test/empty"]) -> str:
       """
       URL: /test/empty
       """
       if config.is_production_mode():
           return quart.abort(404)
   ```
   
   #### `atr/post/test.py` — `test_empty` (lines 30-38)
   _currently does this_
   Test POST route already uses @post.typed decorator — the standard blueprint 
decorator for type-safe routes.
   
   ```python
   @post.typed
   async def test_empty(
       _session: web.Public, _test_empty: Literal["test/empty"], _form: 
form.Empty
   ) -> web.WerkzeugResponse:
       """
       URL: /test/empty
       """
       if config.is_production_mode():
           return quart.abort(404)
   ```
   
   #### `atr/post/test.py` — `test_multiple` (lines 30-38)
   _currently does this_
   Another test POST route using the standard @post.typed decorator, confirming 
all test routes are already consistent.
   
   ```python
   @post.typed
   async def test_multiple(
       _session: web.Public, _test_multiple: Literal["test/multiple"], 
multiple_form: shared.test.MultipleForm
   ) -> web.WerkzeugResponse:
       """
       URL: /test/multiple
       """
       if config.is_production_mode():
           return quart.abort(404)
   ```
   
   #### `atr/blueprints/common.py` — `build_path` (lines 80-87)
   _currently does this_
   The shared path-building infrastructure used by both @get.typed and 
@post.typed — the same code path serves both production and test routes.
   
   ```python
   def build_path(
       func: Callable[..., Any],
   ) -> tuple[str, list[tuple[str, type]], dict[str, str], tuple[str, type] | 
None, bool]:
       """Inspect a function's type hints to build a URL path and a validation 
plan.
   
       Accepts URL path params for data, Literal strings for plain URL text, 
and Form params for POST bodies
       Validates that the session param (web.Committer or web.Public) is first, 
and that only one Form param is allowed
       """
   ```
   
   ### Proposed approach
   Based on the prior discussion, the team concluded that separating test 
routes into their own blueprint is undesirable (@sbp's analysis on 2026-03-12). 
@dave2wave's final comment on 2026-03-19 observes that all test endpoints 
already use the standard `@get.typed` or `@post.typed` decorators, implying no 
further action is needed. Code inspection confirms this: all routes in 
`atr/get/test.py` use `@get.typed` and all routes in `atr/post/test.py` use 
`@post.typed`. The test routes follow the same patterns as production routes. 
There is nothing remaining to tidy.
   
   This issue should be closed as resolved/not-needed.
   
   ### Open questions
   - Was there any specific 'type safe code' tidying @sbp had in mind in their 
comment ('We probably should tidy up the new type safe code at least though'), 
or was that addressed separately?
   - Should this issue be closed given @dave2wave's last comment implies 
nothing is left to do and no one has responded in 50 days?
   
   ### Staleness assessment
   
   _opened 72 days ago; last human comment 50 days ago._
   
   Last activity was 50 days ago. The final comment from @dave2wave ('Is there 
anything to do? All of the test endpoints use @get.typed or @post.typed') 
received no response and effectively concludes that the code is already in the 
desired state. The team decided NOT to separate test routes into a new 
blueprint, and code inspection confirms all test routes already use the 
standard typed decorators. There is no remaining actionable work.
   
   **Recommendation: consider closing this issue.** If the maintainer agrees, 
the agent's assessment above provides the rationale to include in a closing 
comment.
   
   _The agent reviewed this issue and is not proposing patches in this run. 
Review the existing-code citations and open questions above before deciding 
next steps._
   
   ### Files examined
   - `atr/blueprints/__init__.py`
   - `atr/post/test.py`
   - `atr/shared/test.py`
   - `scripts/lint/jinja_route_checker.py`
   - `atr/blueprints/api.py`
   - `atr/blueprints/common.py`
   - `atr/get/test.py`
   - `tests/unit/test_blueprints.py`
   
   ---
   *Draft from a triage agent. A human reviewer should validate before merging 
any change. The agent did not run tests or verify diffs apply.*


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to