IndependentNot a client engagement. This study was not commissioned by, affiliated with or endorsed by GitHub Issues or the other organisations discussed. Findings, local experiments and proposed work are identified separately.
Evidence at a glanceWhat we can substantiate.
Required form fields4The pinned form requires a description, reproduction link, system information and package-manager selection. [2]
Local checks passed18 / 18Validation, deduplication, transactional rollback and recovery; these are test outcomes. [1]
Local review task1Two accepted delivery IDs referring to the same fixture issue converge on one business task. [1]
External actions0No comments, labels, emails, issues or other remote actions were created. [1]
Pinned source review + local reliability tests · Studied 12 October 2026 · By SystemVale
The questionSelf-service works only when a useful request survives the handoff into an accountable, recoverable workflow.
1Does the form collect enough evidence for a person to act?
2What happens when the same event arrives again?
3Can processing resume after an interruption without losing or duplicating work?
Scope & methodA bounded question.
A repeatable method.
Vite’s issue-form file at commit dce9fe69d37e957b62f3b5df61a761f7f2f949f5, GitHub’s public webhook documentation, and SystemVale’s own SQLite-backed prototype. The test events are synthetic fixtures, clearly separated from the real form source. We did not inspect private issues, operate a GitHub App, change Vite’s automation or measure its support performance.
Step 01Inspect a real intake contract
Pin Vite’s issue-form source to a commit. Inspect its required fields, optional reproduction steps and logs, initial pending-triage label and required checklist. Review the written missing-reproduction policy without claiming to have tested its enforcement.
Step 02Define the delivery boundary
Use GitHub’s documented signature and delivery identifier as the protocol reference. In the local prototype, verify signed bytes before parsing, validate the event and action, and commit the accepted event to a durable inbox before treating it as accepted.
Step 03Separate delivery from business work
A delivery ID prevents processing the same delivery twice. A separate repository / issue / action-version key prevents two distinct deliveries from creating the same local review task. A worker records completion in the same transaction as that task.
Step 04Inject failures and inspect state
Test modified bytes, missing identifiers, unexpected events, malformed input, duplicate delivery and identity conflict. Inject exceptions before receiver and worker commits, then retry and inspect the persisted rows. All events stay in a temporary local database.
FindingsThe evidence,
and what it means.
01
Pinned source observationThe public form makes the next step more actionable
The Vite form requires four information fields and seven checklist options. It asks for a reproduction link rather than relying only on a description. Steps and logs have their own optional fields. The configuration applies a pending-triage label, keeping submission distinct from a reviewed decision. [2]
Why it matters. For a service portal, this suggests a compact evidence contract: ask for the facts needed to route and reproduce the problem, and show what happens next.
02
Interpretation of the form contractA required link does not prove useful evidence
A field being required establishes that input is present; it does not establish that a reproduction is accessible, relevant or complete. The source describes a missing-reproduction process, but this study did not observe actual enforcement or its effect on contributors. [2][3]
Why it matters. Keep an explicit needs-information state and a human decision path. Do not equate form completion with a resolved or accepted request.
03
Documented protocol + local testDurable acceptance and duplicate handling solve different problems
GitHub documents a short response window, a stable delivery identifier for redelivery, and that failed deliveries are not automatically redelivered. Our prototype stores an accepted event before processing and distinguishes repeated delivery from a different event referring to the same issue. [1][4][5][6]
Why it matters. An integration needs durable storage, recovery procedures and business-level duplicate handling. A queue alone does not define any of those policies.
04
Measured boundaryAtomic local work is not an exactly-once remote action
The worker rollback test leaves no partial review task because task creation and completion share one SQLite transaction. That guarantee stops at this database. A comment sent to a remote API could succeed just before a worker loses its connection; blindly retrying could duplicate it. [1]
Why it matters. Use the receiving API’s idempotency mechanism where available, or reconcile the remote state before retrying. Human-reviewed drafts are a useful boundary for uncertain actions.
In detailInspect the results.
Observed behaviour of the local prototype| Condition | Expected treatment | Observed |
|---|
| Same ID and signed bytes | Do not enqueue again | Duplicate detected |
|---|
| Same ID, different signed bytes | Flag identity conflict | Conflict returned |
|---|
| Changed bytes, old signature | Reject before processing | Unauthenticated |
|---|
| Receiver fails before commit | Retry can be accepted | Rolled back, then accepted |
|---|
| Worker fails before commit | No partial task; retry | Zero partial tasks, then complete |
|---|
| Second ID for the same issue | Consume event; avoid another task | One review task across two deliveries |
|---|
| No queued work after restart | No extra action | Worker returns empty |
|---|
These are controlled fixture tests of SystemVale’s implementation. They do not measure GitHub delivery reliability or Vite’s production workflow. [1]
Protocol model and reproduction
Run python scripts/study-webhook-reliability.py from the evidence bundle. It uses only the Python standard library, a visibly labelled local test signing value and a temporary database. The complete assertions and actual results are included. The Vite source snapshot retains its MIT license.
Receive:
verify signature against raw bytes
validate event, action and business identity
transaction: insert delivery ID + payload hash + queued state
Worker:
transaction: claim queued record
insert review task if business key does not exist
mark delivery complete
Business key = repository ID + issue number + action version
Remote actions require a separate idempotency / reconciliation design.
Recommendations · not deployedWhat we would do next.
These are SystemVale’s recommendations for a comparable product or service. They are not claims that the organisations studied implemented them.
01Model a small, explicit state machine
Proposed states for a service request: received, needs information, ready for review, approved, executing, completed and failed. Assign an owner and permitted transitions. Record the evidence for a transition rather than inferring completion from an event arriving.
Keep acceptance separate from execution
For an Azure implementation, a function could validate the incoming event and durably queue it before returning; a worker could prepare the review task. This is an architecture proposal, not a deployed or load-tested Azure result. Verify persistence, duplicate handling and timeout behaviour before release.
Add recovery as an operating procedure
Track event age, repeated failures, identity conflicts and pending review tasks. Reconcile missed deliveries using the provider’s supported interfaces. Route exhausted retries to an owned failure queue instead of retrying forever or silently dropping them.
Bound AI to assistance
If AI summarises a request or suggests a category, retain the original evidence and mark its output as a draft. Keep authority to close requests, send responses or change business records in an explicit, auditable approval step. This study uses no model-generated decisions.
SystemVale’s conclusionDesign the recovery path and the business identity before connecting intake to irreversible actions.
Our interpretation of this study. Not a client quote or endorsement.
ApplicationWhat this brings to your work.
01Ask for actionable evidence
A self-service form should reduce avoidable back-and-forth while leaving a clear route for incomplete requests.
02Expect repeated delivery
The event identifier and the business task identifier answer different duplicate-detection questions.
03Make the guarantee precise
A local transaction can be atomic. A distributed workflow needs a separately designed recovery contract.
Explore Self-Service & Workflows →
Limits & sourcesCheck the evidence.
What this study does not establish
- All 18 reliability checks use synthetic events in a local prototype. They are real test results, not real customer or GitHub traffic.
- The receiver is a protocol model, not a deployed HTTP service. Provider integration, concurrency, rate limits, secret rotation and production load remain untested.
- The deduplication guarantee applies to this SQLite database only. No exactly-once guarantee is made for remote side effects.
- No time-saving, ticket-deflection, resolution-rate or support-cost outcome was measured. Vite’s actual automation and moderation were not changed.
Reproduce the analysis
Download the five-study evidence bundle: captured public data, source hashes, scripts, licenses and original result files. The README explains the commands and the boundaries of each experiment.
- SystemVale: all 18 assertions and actual results ↗
Executed 12 October 2026. Synthetic event fixtures; zero remote actions.
- Vite: pinned public issue form ↗
Immutable commit reference, inspected 12 October 2026; source and MIT license in the evidence bundle.
- GitHub: syntax for issue forms ↗
Primary documentation for form fields and required validation.
- GitHub: webhook best practices ↗
Primary delivery contract, including response timing and redelivery identifiers.
- GitHub: handling failed webhook deliveries ↗
Primary documentation for recovery responsibility.
- GitHub: validating webhook deliveries ↗
Primary reference for HMAC SHA-256 verification of received bytes.