CI: bound wiki search backend sync request time #134

New issue

Closed

opened 2026-04-19 03:08:40 +00:00 by pokebedrock-bot · 1 comment

pokebedrock-bot commented

2026-04-19 03:08:40 +00:00

(Migrated from github.com)

Summary

The wiki-search workflow currently syncs build/search-indices.json to the website backend with a bare curl call in .github/workflows/search-index.yml.

Because that call has no connect timeout or overall timeout, a stalled backend/network hop can keep the scheduled or manually-dispatched sync job hanging until the runner-level timeout kills it.

Evidence

Current step on main:

- name: Sync search index via website backend
  if: ${{ secrets.WIKI_SEARCH_SYNC_URL != '' && secrets.WIKI_SEARCH_SYNC_TOKEN != '' }}
  env:
    WIKI_SEARCH_SYNC_URL: ${{ secrets.WIKI_SEARCH_SYNC_URL }}
    WIKI_SEARCH_SYNC_TOKEN: ${{ secrets.WIKI_SEARCH_SYNC_TOKEN }}
  run: |
    curl --fail-with-body --show-error --silent \
      -X POST \
      -H "Authorization: Bearer $WIKI_SEARCH_SYNC_TOKEN" \
      -H "Content-Type: application/json" \
      --data-binary @build/search-indices.json \
      "$WIKI_SEARCH_SYNC_URL"

That means:

a dead TCP connect can wait indefinitely,
a backend that accepts the socket but never responds can also hold the job open,
the daily scheduled sync has no fail-fast signal for this class of outage.

Impact

Scheduled wiki search sync can get stuck instead of failing promptly.
Manual dispatches give maintainers less reliable feedback during backend incidents.
Long-hanging workflow runs waste runner time without adding coverage.

Acceptance criteria

Add an explicit connect timeout and an explicit overall timeout to the backend sync curl step.
Keep the step fail-closed when the sync endpoint is slow/unreachable.
Validate the updated workflow syntax before opening the PR.

## Summary The `wiki-search` workflow currently syncs `build/search-indices.json` to the website backend with a bare `curl` call in `.github/workflows/search-index.yml`. Because that call has no connect timeout or overall timeout, a stalled backend/network hop can keep the scheduled or manually-dispatched sync job hanging until the runner-level timeout kills it. ## Evidence Current step on `main`: ```yaml - name: Sync search index via website backend if: ${{ secrets.WIKI_SEARCH_SYNC_URL != '' && secrets.WIKI_SEARCH_SYNC_TOKEN != '' }} env: WIKI_SEARCH_SYNC_URL: ${{ secrets.WIKI_SEARCH_SYNC_URL }} WIKI_SEARCH_SYNC_TOKEN: ${{ secrets.WIKI_SEARCH_SYNC_TOKEN }} run: | curl --fail-with-body --show-error --silent \ -X POST \ -H "Authorization: Bearer $WIKI_SEARCH_SYNC_TOKEN" \ -H "Content-Type: application/json" \ --data-binary @build/search-indices.json \ "$WIKI_SEARCH_SYNC_URL" ``` That means: - a dead TCP connect can wait indefinitely, - a backend that accepts the socket but never responds can also hold the job open, - the daily scheduled sync has no fail-fast signal for this class of outage. ## Impact - Scheduled wiki search sync can get stuck instead of failing promptly. - Manual dispatches give maintainers less reliable feedback during backend incidents. - Long-hanging workflow runs waste runner time without adding coverage. ## Acceptance criteria - Add an explicit connect timeout and an explicit overall timeout to the backend sync `curl` step. - Keep the step fail-closed when the sync endpoint is slow/unreachable. - Validate the updated workflow syntax before opening the PR.

smell-of-curry commented

2026-10-06 16:04:08 +00:00

Owner

Already fixed on main by 47c8890 (PR #135). .github/workflows/search-index.yml sync curl uses --connect-timeout 10 and --max-time 30 (lines 48-50). The step still posts build/search-indices.json with WIKI_SEARCH_SYNC_TOKEN on the private runner, and still skips the post when either secret is unset.

Already fixed on `main` by `47c8890` (PR #135). `.github/workflows/search-index.yml` sync curl uses `--connect-timeout 10` and `--max-time 30` (lines 48-50). The step still posts `build/search-indices.json` with `WIKI_SEARCH_SYNC_TOKEN` on the `private` runner, and still skips the post when either secret is unset.

smell-of-curry closed this issue

2026-10-06 16:04:08 +00:00