fix(e2e): restore Elasticsearch and search-ingest to the test stack - #488
Merged
Conversation
The e2e CI job has failed on every run since 2026-08-13. It dies in "Bring
up the local PlaceOS stack", where the seed's first API call comes back 500:
GET /api/engine/v2/oauth_apps?limit=500 -> 500
Error connecting to '127.0.0.1:9200': Connection refused
16dc58f removed Elasticsearch and search-ingest on the basis that PPT-2644
serves search from Postgres. That is true of rest-api's master branch, but
the stack pins ${PLACEOS_TAG:-latest}, and `latest` is the RELEASE channel:
it currently resolves to placeos-2.2608.1 (revision 54ab6262, built
2026-08-11), which was cut before PPT-2644 landed and still expects
Elasticsearch. With no `elastic` service it falls back to its default host,
127.0.0.1:9200, and every index route 500s.
The commit that removed them said so itself — "do not merge before rest-api
images with PG-backed search are published" — and was merged before that
happened. It went unnoticed for 11 days because the job is advisory and
nothing alerts on it.
This is a straight revert of the stack half of 16dc58f, plus a note on the
`elastic` service recording the constraint that was violated and how to
check it before removing them again. All six files are byte-identical to
the last known-green state.
Re-apply 16dc58f once `latest` carries PPT-2644; it reverts cleanly. As of
today that is true of `nightly` and not of `latest`.
Verified on an isolated copy of the stack (project placeos-e2e-verify,
ports 9081/9444) against placeos/*:latest: `up.sh --fresh` seeds and
returns clean, and the suite runs 13 passed / 1 flaky / 0 failed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The workplace e2e job has failed on every run since 13 August. Alex flagged it. This gets it green again.
What was happening
The job dies in "Bring up the local PlaceOS stack", on the first API call the seed makes:
16dc58f removed Elasticsearch and search-ingest from the stack because PPT-2644 moved rest-api's search onto Postgres. That is true of rest-api master, but the stack pins
${PLACEOS_TAG:-latest}andlatestis the release channel, not develop. Right now it resolves toplaceos-2.2608.1(revision54ab6262, built 11 August), which was cut before PPT-2644 landed and still expects Elasticsearch. With noelasticservice in the stack it falls back to its default host of127.0.0.1:9200, so every index route 500s.The commit that removed them said as much in its own message ("do not merge before rest-api images with PG-backed search are published"). It got merged before that happened.
What is in here
A straight revert of the stack half of 16dc58f. All six files are byte-identical to the last known-green state, so there is no new code to review.
The one addition is a note on the
elasticservice that records the constraint this ran into, and how to check it before removing these again:Today that is false for
latestand true fornightly. Once a release carrying PPT-2644 is cut (2.2608.2 is not published yet), re-apply 16dc58f rather than redoing the work. It reverts cleanly.Verification
Run on this branch: 32687443655, 14 passed, 0 flaky, 2m46s on the self-hosted runner. That matches the pre-break baseline.
Also checked locally first, on an isolated copy of the stack (project
placeos-e2e-verify, ports 9081/9444) againstplaceos/*:latest, so the running singleton was untouched:up.sh --freshseeds and returns clean, suite 13 passed / 1 flaky / 0 failed.Two things worth a separate look
ensureOAuthAppinseed.tscan report success when it created nothing. rest-api enforces uniqueness on the appnameas well as the uid, andalreadyExists()matches any "should be unique" failure, including one onname. Seeding a second dev-server port against the same stack prints "oauth app present" while no app with that uid exists. It does not affect CI (one port), but it is the same "passes for the wrong reason" shape Alex called out on test(e2e): PKCE-on-the-wire, per-user scoping, and desk clash coverage #477. Happy to fix separately.