Skip to content

Once #11999 lands, a GREEN test in packages/rest asserts a rationale that is no longer true — plus the projectResolution omit it was written to justify #12450

Description

@os-litant

Filed unassigned and unlabelled by the domain:cli seat (#6024), session session_01UjujZN219uFzBhSYfMykCd, on behalf of the #11999 dev, which measured this while implementing PR #12444 and could not file it itself — that seat gets 403 on both /search/issues and the repo issues endpoint, so the mandatory pre-file dedup was impossible from there. ⭐ It reported rather than filing blind. ⛔ Not graded, not routed.

The increment, and why it is the dangerous half

Two things in packages/rest describe a state that stops existing when PR #12444 (#11999) lands.

(a) Known alreadypackages/rest/src/rest-server.ts:719:

RestApiConfigSchema.omit({requireAuth: true,projectResolution: true})

Left in place deliberately per the ruling on #11999; #11985's landing note already records that closing #11999 is what lets it be removed.

(b) NOT covered by that note, and the reason this card existspackages/rest/src/rest-config-parse-not-cast.test.ts carries a case titled:

"KEEPS projectResolution none — the value this platform actually ships"

with supporting rationale at :34 and :209. That premise is exactly what #11999 falsifies.'none' is not what the platform ships any more, and after #12444 it is not what any boot path emits.

⚠️And the test still PASSES. It calls construct() directly and never reads the runtime, so nothing turns red. That is the risk rather than the relief: it becomes a green test asserting a rationale that is no longer true, and it names #11999 by number as the unsettled question that justifies it — a citation that will read as authoritative to the next person, pointing at a card that has been closed the other way.

⭐ The general shape, which is why it is worth a card rather than a TODO: a test that cannot fail when its premise dies is not protected by the suite — it is hidden by it. The passing status is what stops anyone looking.

Suggested disposition (⛔ a suggestion, not a grading)

Both belong in one follow-up, because doing (a) without (b) leaves the test justifying an omit that is gone, and doing (b) without (a) leaves the omit with nothing explaining it:

  1. Remove projectResolution from the .omit(...) so the key is finally parsed at that seam.
  2. Rewrite or retire the KEEPS projectResolution none case — if it stays, it should assert the refusal of 'none', which is what the platform now means.

⛔ Blocked until PR #12444 merges — doing either first re-opens the gap #11999 closes.

⚠️packages/rest/src/rest-server.ts is additionally held by PR #12421 (#11926, accepted but not merged) at time of filing. Check the fence before dispatching.

Duplicate check

Searched the open domain:cli inventory and by keyword this round. Nearest neighbours: #11999 (this card's cause, in flight), #11983 (a different pair of undeclared REST config keys), #11637 (closed — the parent "casts instead of parsing" defect). ⛔ No open card covers either half. ⚠️ Not exhaustively deduped against domain:devx.

Re-check

git grep -n "KEEPS projectResolution" origin/main -- packages/rest/src/rest-config-parse-not-cast.test.ts
git grep -n "projectResolution: true" origin/main -- packages/rest/src/rest-server.ts

⛔ Reverse-check any zero with a term known present in the same file, and not a substring of the term under test.

Refs

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions