Skip to content

fix(wavey-gist): use new files-snapshot payload for create endpoint - #326

Merged
spalen0 merged 1 commit into
mainfrom
fix/wavey-gist-files-snapshot
Jul 28, 2026
Merged

fix(wavey-gist): use new files-snapshot payload for create endpoint#326
spalen0 merged 1 commit into
mainfrom
fix/wavey-gist-files-snapshot

Conversation

@spalen0

@spalen0 spalen0 commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

Summary

utils/wavey_gist.upload_to_gist was posting the legacy payload shape ({title, markdown}) to Wavey Gist. The API now rejects unknown fields with HTTP 400:

Legacy gist fields are no longer supported. Send a files snapshot and include expected_snapshot_sha256 for updates.

raise_for_status() turned the 400 into requests.HTTPError, which the existing try/except (requests.RequestException, ValueError) swallowed. The caller (format_explanation_line in utils/llm/ai_explainer.py) then fell through to ⚠️ Couldn't post full report in the Telegram message. The Telegram summary still shipped — only the linked detail was lost.

This is the same payload that powers every AI report link in production (e.g. timelock alerts, governance-proposal walkthroughs). Whenever an explanation had a detail long enough to be sent to gist, the team got the warning instead of a working link.

Reproduction (against the prod WAVEY_GIST_API_KEY)

POST https://api.wavey.info/api/v1/gists
{ "title": "test", "markdown": "# test\n\n..." }
→ 400 {"error":{"code":"invalid_request",
      "message":"Legacy gist fields are no longer supported. ..."}}

Fix

Switch the create payload to the documented files-snapshot shape and put the report under README.md (the API's preferred primary filename, so the rendered page opens with the content):

{
  "title": "AI Transaction Analysis",
  "files": { "README.md": { "content": "# AI Transaction Analysis\n\n..." } }
}

Response shape ({url, id, primary_file, files, snapshot_sha256, ...}) is otherwise compatible — only the request body needed to change.

Live-validated with the production key after the patch: Status 201, gist renders with the correct title and README.md as the primary file.

Tests

  • test_successful_upload: assert the legacy markdown field is gone and the content lives at files[README.md].content.
  • test_no_title_sends_raw_content: reworked to match the new shape.
  • test_http_error_returns_empty (new): covers the exact failure mode that triggered this incident — the function must keep alerting and return "" so the in-Telegram summary still ships even when gist is down or its schema changes again.

All 7 test_wavey_gist.py cases pass; ruff format and ruff check clean.

Backfill

Pushed a follow-up gist for the InfiniFi LongTimelock call (tx 0xf61f9e5af62d4ec67b8b6ef71524226236e5d30acb1945531181b4e497c765f3) that surfaced this — see the [Full details] link posted in the original thread.

Wavey Gist's create endpoint now rejects the legacy
{title, markdown} fields with HTTP 400. Switch to the
files-snapshot format documented at https://gist.wavey.info/llms.txt:

  { title, files: { README.md: { content: ... } } }

README.md is picked as the primary file by the API, so the
rendered page opens with our content. response.raise_for_status()
turns the API's 400 into a requests.HTTPError; the existing
try/except already swallowed it and the caller fell through to
"Couldn't post full report". The bug was invisible until the
silent failure showed up in production alerts.

Live-validated against the production WAVEY_GIST_API_KEY
(Status 201, gist renders with title and primary README.md).

Tests:
  - test_successful_upload: assert legacy 'markdown' field is gone
    and content is now in files[README.md].content
  - test_no_title_sends_raw_content: reworked to match
  - test_http_error_returns_empty: new, covers the 400-on-legacy-
    payload failure mode that caused this incident
@spalen0
spalen0 marked this pull request as ready for review July 28, 2026 14:48
@spalen0
spalen0 merged commit 3735182 into main Jul 28, 2026
3 checks passed
@spalen0
spalen0 deleted the fix/wavey-gist-files-snapshot branch July 28, 2026 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant