docs: the edge-only list is not about the hop count, and the pod is two pods #37

Merged

jlxq0 merged 1 commit from docs-hops-caveat into main

2026-08-27 04:40:16 +00:00

jlxq0 commented

2026-08-27 04:37:43 +00:00

Owner

Documentation only.

Clark's caveat, put where a reader of this code meets it rather than only in the manifest: being on the edge-only route list is not a statement that this hop count is right, and fixing the hop count is not a reason to come off it. The list is about which routes must stay edge-only. The two facts are independent and were established in the same hour, which is precisely why the next person will conflate them.

The parentRef invariant, enumerated cluster-wide rather than for this service alone, independently of jmap-mcp's count:

89 HTTPRoutes   max parentRefs = 1   with more than one = 0

Unanimous, so the platform assertion is free to satisfy today rather than merely cheap to write.

And a finding from checking both deployments rather than the one I expected. Production and beta are two pods, on two images, from two tags, under two manifests:

production  sha256:10865c38  v0.2.2                        default = 2
beta        sha256:1a8e184c  v0.2.0-beta.20260826140543    default = 1

Deleting beta's override today would inherit 1 and record the gateway's address, while deleting production's is safe. That is the three-step trap arriving asymmetrically because only one deployment has rolled. I have pushed main to beta so a beta image carrying the new default is minting.

It also corrects something I said earlier: the count line settles the hops question for whichever deployment produced the line. I had been treating "the pod" as one thing since the rollout.

Documentation only. **Clark's caveat, put where a reader of this code meets it** rather than only in the manifest: being on the edge-only route list is not a statement that this hop count is right, and fixing the hop count is not a reason to come off it. The list is about which routes must stay edge-only. The two facts are independent and were established in the same hour, which is precisely why the next person will conflate them. **The `parentRef` invariant, enumerated cluster-wide rather than for this service alone**, independently of `jmap-mcp`'s count: 89 HTTPRoutes max parentRefs = 1 with more than one = 0 Unanimous, so the `platform` assertion is free to satisfy today rather than merely cheap to write. **And a finding from checking both deployments rather than the one I expected.** Production and beta are two pods, on two images, from two tags, under two manifests: production sha256:10865c38 v0.2.2 default = 2 beta sha256:1a8e184c v0.2.0-beta.20260826140543 default = 1 **Deleting beta's override today would inherit 1** and record the gateway's address, while deleting production's is safe. That is the three-step trap arriving asymmetrically because only one deployment has rolled. I have pushed `main` to `beta` so a beta image carrying the new default is minting. It also corrects something I said earlier: the count line settles the hops question **for whichever deployment produced the line**. I had been treating "the pod" as one thing since the rollout.

jlxq0 added 1 commit

2026-08-27 04:37:43 +00:00

docs: the edge-only list is not about the hop count, and the pod is two pods

CI / cargo (pull_request) Successful in 1m0s

Details

CI / docker (pull_request) Successful in 1m16s

Details

d06327d86f

Clark's caveat, recorded where a reader of this code will meet it rather than
only in the manifest: being on the edge-only route list is not a statement that
this hop count is right, and fixing the hop count is not a reason to come off
it. The list is about which routes must stay edge-only. The two facts are
independent and were established in the same hour, which is exactly why they
will be conflated.

The parentRef invariant is now enumerated cluster-wide rather than for this
service alone: 89 routes, none carrying more than one, so the platform
assertion is free to satisfy today rather than merely cheap to write.
Independently of jmap-mcp's count.

And a finding from checking rather than assuming: production and beta are two
pods on two images from two tags under two manifests. Production runs v0.2.2
with the corrected default; beta still runs a v0.2.0-beta image with the old
one. Deleting beta's override today would inherit 1 and record the gateway as
the client, while deleting production's is safe. I had been treating "the pod"
as one thing since the rollout, including when I said the count line settles
the hops question from one real request.

jlxq0 merged commit 5a97927d0a into main

2026-08-27 04:40:16 +00:00

jlxq0 deleted branch docs-hops-caveat

2026-08-27 04:40:16 +00:00

jlxq0 referenced this pull request from a commit

2026-08-27 04:40:17 +00:00

Merge pull request 'docs: the edge-only list is not about the hop count, and the pod is two pods' (#37) from docs-hops-caveat into main