antigravity: paid row rotates among three readings; fetchedAt moves backwards

[iceteaSA]

On build 5932626c4e6f, the paid antigravity row publishes three different readings in rotation, and fetchedAt moves backwards. The three free rows on the same provider, in the same process, in the same samples, behave correctly — which is what makes this reportable rather than ambient noise.

Accounts are labelled A–D below; A is the paid one (capturedPaidTierId = g1-pro-tier), B/C/D are free-tier.

Observed

82 samples, 3s apart, all four antigravity accounts read from the same usage.get response each time.

Account A cycles among three distinct readings:

 37x  source=oauth  usedPercent=32.73  fetchedAt=2026-09-11T18:19:36
 25x  source=oauth  usedPercent=33.49  fetchedAt=2026-09-11T19:02:47
  7x  source=oauth  usedPercent=13.88  fetchedAt=2026-09-11T19:15:37
  5x  source=vault  usedPercent=32.73  fetchedAt=2026-09-11T18:19:36

Accounts B, C, D over the same samples:

 B   5 distinct (usedPercent, fetchedAt) tuples, ONE usedPercent:  50.86
 C   5 distinct (usedPercent, fetchedAt) tuples, ONE usedPercent: 100.0
 D   5 distinct (usedPercent, fetchedAt) tuples, ONE usedPercent: 100.0

Five tuples on a free row is fetchedAt advancing normally — 19:17:11, 19:18:12, 19:19:13, 19:20:14, one per ~61s fetch cycle, with the value unchanged. That is the healthy shape. Three tuples on row A is three different values alternating, none of them advancing.

Two consequences fall out.

fetchedAt moves backwards. Measured once inside a single instrument run: a 3361s step, 19:15:37 → 18:19:36. Rotating among frozen timestamps makes it non-monotonic by construction, not by accident.

The same reading publishes under two different source labels. (32.73, 18:19:36) appears 37 times as oauth and 5 times as vault — identical value, identical timestamp, different provenance. A consumer counting vault-backed lanes sees the count flap. That is how I found this: a routine sweep read 6 vault rows, then 5, twenty seconds apart, with nothing having changed.

Why it matters

A router reading headroom for account A gets 13.88% or 32.73% depending on which sample it catches — a 19-point swing with no underlying consumption change. The stalest of the three readings was an hour old while a 3-minute-old one existed in the same rotation, so a freshness gate does not select the good one; it accepts whichever happens to be published.

This compounds with a consumer-side defect found separately today: at least one downstream consumer does not deserialize fetchedAt at all and stamps its own poll time, so every one of these readings looks 0s old to it. A staleness gate cannot filter a field the consumer never reads, and here even a consumer that did read it would be handed a timestamp that goes backwards.

Hypothesis, stated as one

I have not established the mechanism, only the observable. The shape is consistent with more than one slot resolving to account A — a vault handle whose identity is that account, plus the plugin account of the same identity — deduplicating to a single published row whose winner is not stable across snapshots, each slot carrying its own last-good cached value. The alternating source label on an otherwise identical reading is what suggests it. Exactly four antigravity rows are published in every sample, so whatever the count of underlying slots, dedup is always collapsing them; it is the choice of winner that varies.

Worth saying plainly: this is specific to the account that takes the paid-tier refusal path. The free rows resolve through the cloud lane and are stable. I would look first at what the refusal leaves behind for dedup to choose from.

What I did not establish

• Whether the three readings correspond to three distinct slots, or to two slots plus a cache that changed mid-run.
• Whether this predates the current build. I only started sampling today, so I cannot date its onset.
• Whether it occurs on a host with a single antigravity account. Four accounts plus one vault handle may be load-bearing for reproducing it.

Instrument and raw log available if useful. Happy to run a specific probe if there is one that would discriminate between the hypotheses above — I would rather collect the evidence you want than argue from the evidence I happened to collect.

[iceteaSA]

Correcting a count in the report above. I filed "three readings" from 82 samples while the capture was still running. The completed run — 400 row-samples, 100 snapshots × 4 accounts — shows four distinct readings on account A, not three:

 38x  source=oauth  usedPercent=33.49  fetchedAt=2026-09-11T19:02:47
 37x  source=oauth  usedPercent=32.73  fetchedAt=2026-09-11T18:19:36
 12x  source=oauth  usedPercent=33.49  fetchedAt=2026-09-11T19:11:28
  7x  source=oauth  usedPercent=13.88  fetchedAt=2026-09-11T19:15:37
  5x  source=vault  usedPercent=32.73  fetchedAt=2026-09-11T18:19:36
  1x  source=vault  usedPercent=33.49  fetchedAt=2026-09-11T19:11:28

Two things the larger sample adds, both of which sharpen rather than soften the original report:

usedPercent alone does not identify a reading. 33.49 appears against two different fetchedAt values, 19:02:47 and 19:11:28 — the same percentage observed at two different times, rotating as separate readings. Anything keying on the value to detect change will see those two as identical and miss the rotation entirely.

The vault label is not attached to one reading. In the 82-sample window it appeared only on (32.73, 18:19:36), which made a one-slot-one-label story look plausible. Over the full run it also appears on (33.49, 19:11:28). So the label and the reading vary independently, which weakens any explanation that pairs a fixed label to a fixed cached value.

The control is unchanged and now rests on 100 snapshots rather than ~20: accounts B, C and D each hold exactly one usedPercent across the entire run, with fetchedAt advancing one step per fetch cycle.

Correcting this because the count was wrong in a direction that understated the problem, and because the number came from a sample I described as complete while it was still filling. The instrument was mid-run when I read it.

[qta-alfonso]

Confirmed, reproduced at source, fixed in two parts, and deployed — e0e1416, live here
with buildCommit e0e1416d3fde. Your hypothesis was right, including the mechanism you
said you had not established.

What it was

Two slots resolve account A — a vault handle and a plugin account of the same identity —
and they deduplicate to one published row. The tie-break ordered on fetch completion:

rank.then_with(|| current.last_success_at.cmp(&slot.last_success_at))

That was a correct proxy for "describes the account more recently" — the rule the comment
above it states — for exactly as long as every lane fetched its value at the moment it
polled. I shipped a lane yesterday that does not: for a paid-tier account the correct pool
is visible only to the local editor, so with the editor closed the row is served from that
editor's plugin cache and carries the cache's timestamp rather than ours.

So each slot captured a different snapshot of that cache, and then alternated as winner by
whichever had polled last — publishing whichever snapshot it happened to be holding. Every
observable you listed falls out of that: four readings in rotation, one percentage against
two different timestamps, fetchedAt stepping backwards, and the free rows stable because
their value time and fetch time still agree by construction.

Your inference from the source label was the load-bearing one. It is the only clue on
the wire that distinguishes "one slot with a changing value" from "several slots taking
turns", and it is what you led with.

The fix, and the part of it I got wrong first

Ordering is now on last_success_wall — the field published as fetchedAt — so the winner
and its timestamp agree by construction and a stable account set cannot walk backwards.

That fixed the value rotation and not the label flap. I had left monotonic fetch time as
a tier beneath it, reasoning it could still separate two different readings sharing a wall
stamp. It cannot: wall stamps carry nanoseconds, so two readings sharing one are one
reading — and the tier fired on exactly the case it was supposed to defer on, flipping the
winner anyway. The last resort is now the handle, which is arbitrary and constant.

Worth saying how that surfaced, since it is the same failure twice: my first test for the
label used a fixture whose source string was a constant for every handle, so it compared one
literal against itself and passed however the winner was chosen. It reddened nothing under
mutation. The fixture now names the handle in the source.

Measured after

15 samples, 4s apart, editor closed:

paid row    1 reading, 1 source label   (7.5% @ 20:45:58, all 15)
free row    1 reading, 1 source label   fetchedAt advancing one step per cycle

Two fetchedAt values on the free row across the window is the healthy shape you
described — the value unchanged, the timestamp advancing ~61s per fetch.

On the report itself

The correction you posted is the part I would keep. You filed "three readings" from a
sample you described as complete while the instrument was still running, then corrected to
four with the reason stated — and both additions sharpened the report rather than softening
it. usedPercent not identifying a reading, and the label varying independently of the
value, are the two facts that would have sent me down a wrong path had the first count
stood: I would have looked for one cached value per label.

Nothing further needed from you. Leaving it open briefly in case the rotation returns under
a shape my 15 samples did not cover — your 100-snapshot instrument is a better witness than
mine, and I would rather you close it than have me close it on my own evidence.