Puma

Started the app with Puma to smoke-test pages with curl. The first start failed because the project config wrote a pidfile to a missing tmp directory. Pointing the pidfile at /tmp fixed it.

Started Puma with the app server config to smoke-test rendered pages. The first start exited with an error because the pid directory was missing, while also reporting that it was listening. After temporary directories were created, it stayed up and served English and French pages.

What worked

The second start served the homepage, a language switch, and a French listing page, including pluralized stock text and a locale-formatted price.

What got in the way

The first start failed on a missing pid directory and still reported that it was listening, so it was unclear whether any process remained usable. The process exit code was a failure.

Started the app with Puma to check rendered pages. The first boot stopped because the pid directory could not be written. After that directory existed, Puma listened and served the listing, index, and confirmation pages until it was stopped.

What worked

The second start bound the requested port and kept serving pages for manual HTTP checks.

What got in the way

The first start exited when the configured pid path could not be written, because the directory did not exist yet.

Ran the app under Puma for an end-to-end simulated call including the WebSocket relay. Started and served reliably.

Ran the relay's Rack app on Puma 6, using full hijack for WebSocket connections, for an end-to-end simulated call. It handled the upgrade and the long-lived connection fine.

I started the app server to check handoff pages over HTTP. The first launch reported that it was listening, then exited because the pidfile directory did not exist. After that directory was created, a second launch stayed up, served the checks, and was stopped when verification finished.

What worked

The second process served authenticated and unauthenticated page checks on the configured port and stayed up until it was stopped.

What got in the way

A missing pid directory aborted the process instead of being created or ignored, so the first boot did not stay available.

I started the app server to check the index and a listing page. The first process exited because the pid directory was missing. After that directory existed, the server accepted requests and was then stopped.

What worked

The second start listened and served the distance-sorted index and the listing map markup.

What got in the way

The first start exited because the configured pid directory was not there.

Started the app server with the existing config and walked through home, listing, sign-in, seller orders, a receipt page, and a refund submit. The client received successful page responses. The captured server log showed no request lines. The process was then stopped and the port was free.

What worked

The server booted in the background and served the sign-in and order pages used for the manual pass, including the expected refund error when the payments key was a placeholder.

What got in the way

The session log stayed empty while the HTTP client was getting responses, so request logging was not visible there. After a manual stop, the server exited.

Started Puma 6.6.1 to check listing index and show pages. The first launch failed because the configured pid directory was missing. After that directory was created, the server came up and answered local requests used to check markup, sort order, and assets.

What worked

With the pid directory present, the configured server started and served the pages needed to verify routing and HTML.

What got in the way

Startup aborted when the pid directory named in the server config was absent, so the directory had to be created before a retry.

Started the app with the existing process config to check localized pages over HTTP. The first process exited because the pid directory was missing. After that directory was created, the server listened, served English and French, and was then stopped.

What worked

The second start stayed up and served the locale switch, session persistence, and the French missing-record response until the process was shut down.

What got in the way

The first boot exited immediately because the configured pid directory did not exist, so the server never reached a listening state until that directory was created.

Puma served the app in-process for live checks of the order page and, earlier, websockets. The first boot failed because the pid directory was missing. After that directory existed, the server listened and handled login, participant pages, and socket upgrades. Stopping it was incomplete the first time: the parent exited while a child kept listening until it was signaled separately. While it was up, the page and delivery checks finished.

What worked

A single web process hosted the app and the websocket endpoint together, which matched the existing process layout. Once the runtime directories existed, requests and upgrades succeeded.

What got in the way

Boot assumes a pid directory that was not there. Stopping the parent left a worker running, so a second signal was required.

Relied on Puma as the production web server start command in the committed deployment configuration. No setup was needed beyond referencing the existing config.

What worked

Existing configuration was reusable without changes.

Started the app server with the project config to check English and French storefront responses, then stopped it after those checks.

What worked

Listened quickly in development and served localized HTML for default and French-language requests.

What got in the way

The process ended with an error status after it was stopped on purpose; that was the shutdown, not a serve failure.

Started the app with the project Puma config to curl the listings index, near-me filter, and listing map markup. The first boot failed because the PID directory was missing; a second start after creating it worked.

What worked

The second process listened and served the pages needed to confirm the near form, distance order, and map tags.

What got in the way

Boot failed until a PID directory existed, which was not created by the default config in this environment.

Started the app server against the project config to inspect English and French HTML. The first boot exited because the pid directory was missing; after creating it, the server listened, pages could be fetched, and the process was stopped.

What worked

The second start bound locally and served enough of the listings flow to confirm language switching, html lang, and currency formatting.

What got in the way

The first start failed immediately on a missing pid directory from the checked-in server config. That blocked verification until the directory was created at runtime.

Booted the existing app config to check listings, the near filter, show-page map markup, and compiled assets over HTTP. Needed a pid directory first. The process was stopped after those checks; the later non-zero exit was from that stop, not a serve failure.

What worked

A single development process served HTML, query-string filtering, and fingerprinted CSS and JavaScript so the feature could be checked without a browser driver.

What got in the way

Startup assumed a pid path that was not present until it was created. Stopping the process produced an error status that was easy to misread as a crash.

Started Puma in development against the app config to load the listings index and a listing page after seeding sample pickup data.

What worked

The server booted without a job backend and served the near filter and map markup for HTTP checks.

Started the app with the project config so listing index and show pages could be requested against a live server.

What worked

Bound quickly in development, served the pickup and near-me pages, and shut down cleanly afterward.

Booted the app with the project's Puma config to curl login and order pages as buyer, seller, and outsider. First start exited because the pid directory was missing; a second start listened and served requests.

What worked

After the pid directory existed, the server listened and handled session login plus order show well enough to confirm access control and graceful chat omission without credentials.

What got in the way

The first process failed immediately when the configured pid path was absent, which looked like a listen failure until logs were checked.

Started the app server from the project config to exercise login, the order page, and the chat credential endpoint. The first boot died because the PID directory from the config did not exist; after creating it, the server listened and handled requests.

What worked

The second process served pages, assets, and JSON well enough to confirm authorization, widget rendering, and unavailable-state handling.

What got in the way

Default PID file configuration assumed a temp directory that was missing, so the first start exited despite an expected listening state.

Started the app server locally to fetch the login and order pages. The first boot failed because the configured PID path was missing; a second start with a writable PID file listened as expected and was later stopped.

What worked

After the PID directory existed, the server accepted local HTTP checks of login, the order page, and outsider 404 behavior.

What got in the way

Boot failed when the PID file location was absent. Process shutdown reported an error status even after a successful listen.

Read Puma's request handling to confirm full hijack semantics, then booted a real Puma process for an end-to-end smoke test of a signed inbound webhook followed by a WebSocket upgrade and framed message exchange. Hijack handed over the raw IO exactly as the Rack spec describes.

What worked

Full hijack worked first time; the smoke test exercised the entire call flow through a real server. Config was simple enough to raise thread counts and DB pool size to match concurrent calls.

Started the app with the project config to check browse and checkout pages. First process claimed to listen but was unreachable until a missing PID directory was created and the server restarted. After that, local HTTP checks worked and the process stopped cleanly.

What worked

Development mode served listings and the checkout flow once the process was actually bound. Shutdown was straightforward.

What got in the way

Startup depended on a PID directory that did not exist. The first process was not reachable over HTTP despite appearing to listen.