Take the e2e poll vectors and check them in CI #178

2026-09-24T18:09:46Z

paulhitt commented

2026-09-24 18:09:46 +00:00

(Migrated from gitlab.com)

The other half of a change that was split so F6 could land on its own.

What happened, because it is the useful part

PollTallyVectorTest was written, passed locally, and failed in CI with three AssertionError at PollTallyVectorTest.kt:40 — which is "vectors not found".

The fixture lives in flamenet-e2e. CI clones that repo at the commit .e2e-ref pins, and the file only existed on an unmerged branch. It passed on a developer machine because there is a sibling flamenet-e2e checkout there and the runner has none.

That is not a defect in the test. It is this repo's cross-repo process working exactly as designed, and it is the "pushed is not green" lesson in its purest form: the machine that ran it green could not have caught it.

So, in one commit as `.e2e-ref.md` asks

.e2e-ref moves to e2e main
FLAMENET_POLL_VECTORS joins the export list and the existence check that runs before the suite
the test comes back

That existence check is why the loop above it exists in the first place: a path that silently does not exist puts the tests straight back where they were, and the failure then reads as a protocol bug rather than a missing file.

What the test is for

Both engines carry a comment saying the integer width is load-bearing — Int32 with &+/&- on iOS, JVM Int here — because the same shares add up to a different number at 64 bits and the two engines would disagree about the result of a vote. Both were unit-tested on their own side and nothing checked that they agree, while a mixed iPhone-and-Android group poll is the ordinary case. A disagreement surfaces as a wrong count rather than an error: no crash, the poll closes on the wrong answer and everybody believes it.

Two of the four cases come out differently if a reader widens to 64 bits and carry the wrong answer beside them; the other two agree by luck, which is the point of the wrapping cases.

Verified both ways it can be reached

With FLAMENET_POLL_VECTORS set, as CI sets it, and with it unset so the sibling-checkout fallback is what answers.

client 480, engine 723, app 652, no failures. The vector suite itself: 3 tests, 0 skipped, 0 failures.

🤖 Generated with Claude Code

The other half of a change that was split so F6 could land on its own. ## What happened, because it is the useful part `PollTallyVectorTest` was written, passed locally, and failed in CI with three `AssertionError at PollTallyVectorTest.kt:40` — which is "vectors not found". The fixture lives in flamenet-e2e. CI clones that repo **at the commit `.e2e-ref` pins**, and the file only existed on an unmerged branch. It passed on a developer machine because there is a sibling `flamenet-e2e` checkout there and the runner has none. That is not a defect in the test. It is this repo's cross-repo process working exactly as designed, and it is the "pushed is not green" lesson in its purest form: the machine that ran it green could not have caught it. ## So, in one commit as `.e2e-ref.md` asks - `.e2e-ref` moves to e2e `main` - `FLAMENET_POLL_VECTORS` joins the export list **and the existence check that runs before the suite** - the test comes back That existence check is why the loop above it exists in the first place: a path that silently does not exist puts the tests straight back where they were, and the failure then reads as a protocol bug rather than a missing file. ## What the test is for Both engines carry a comment saying the integer width is load-bearing — `Int32` with `&+`/`&-` on iOS, JVM `Int` here — because the same shares add up to a different number at 64 bits and the two engines would disagree about the result of a vote. Both were unit-tested on their own side and nothing checked that they agree, while a mixed iPhone-and-Android group poll is the ordinary case. A disagreement surfaces as a wrong count rather than an error: no crash, the poll closes on the wrong answer and everybody believes it. Two of the four cases come out differently if a reader widens to 64 bits and carry the wrong answer beside them; the other two agree by luck, which is the point of the wrapping cases. ## Verified both ways it can be reached With `FLAMENET_POLL_VECTORS` set, as CI sets it, and with it unset so the sibling-checkout fallback is what answers. --- **client 480, engine 723, app 652, no failures.** The vector suite itself: 3 tests, 0 skipped, 0 failures. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

paulhitt commented

2026-09-25 11:49:53 +00:00

(Migrated from gitlab.com)

added 1 commit

f1cd145c - Export the poll vectors in vectors-head too

Compare with previous version

added 1 commit <ul><li>f1cd145c - Export the poll vectors in vectors-head too</li></ul> [Compare with previous version](/paulhitt/flamenet-messenger-android/-/merge_requests/151/diffs?diff_id=2053743464&start_sha=e48907077c67c2ca08237b584e9683e9da62d99f)

paulhitt commented

2026-09-25 12:35:25 +00:00

(Migrated from gitlab.com)

mentioned in commit 6ce2f59e0f

mentioned in commit 6ce2f59e0fdc8207a257810fcbf097a3ff5ca88b

paulhitt (Migrated from gitlab.com) merged commit 6ce2f59e0f into main

2026-09-25 12:35:25 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#178

Take the e2e poll vectors and check them in CI #178

What happened, because it is the useful part

So, in one commit as .e2e-ref.md asks

What the test is for

Verified both ways it can be reached

So, in one commit as `.e2e-ref.md` asks