Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Document what the API does for a deleted destination

Open
  • Is something wrong?
#1,115 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Domain
api, documentation

Research direction

Read the decisions and implementation in #65 and #121, plus the event-delivery change in #1109. Confirm with maintainers whether reusing a deleted destination's ID should be supported or changed; that decision is still open. Then add the behavior table and the agreed ID-reuse behavior to the destinations or event delivery documentation, and verify the text covers behavior both before and after the seven-day record expiry.

Written by the indexing model from the issue text.

Description

How deletion behaves was decided in #65 and implemented in #121, but it is not written down anywhere a user or contributor would look. #1109 adds one paragraph to the event delivery page. This issue is to record the full behaviour as a decision, and to confirm the one part that was never discussed: reusing the ID.

Behaviour

A deleted destination keeps a record in the tenant store, marked deleted, for 7 days. Its events and attempts stay in the log store.

Request Before delete After delete
GET, PATCH, DELETE /tenants/:tenant_id/destinations/:destination_id, PUT …/enable, PUT …/disable 200 404 destination not found
GET …/destinations/:destination_id/attempts and …/attempts/:attempt_id 200 404 destination not found (as of #1109)
GET /tenants/:tenant_id/destinations lists it does not list it
GET /attempts?destination_id=…, GET /attempts/:attempt_id 200 200, the history stays readable
the same with include=destination destination object on each attempt no destination field
GET /events?destination_id=…, GET /events/:event_id 200 200
POST /retry with its destination_id 202 404 destination not found (as of #1109)
POST /tenants/:tenant_id/destinations with its id 400 destination already exists 201

Nothing changes when the record expires after 7 days: every row answers the same.

Events still queued for a deleted destination are acknowledged, not delivered and not logged (#65).

Reusing the ID

A destination can be created again with the ID of a deleted one, right after the delete or after the record expires. Attempts are stored by tenant and destination ID, so the new destination takes over the old one's history:

  • GET …/destinations/:destination_id/attempts lists the attempts made to the deleted destination.
  • include=destination on those attempts returns the new destination.
  • POST /retry for an old event sends it to the new destination, if its topics and filter match.

This only affects a caller that passes its own id and reuses it; generated IDs are not reused.

To do

  • Confirm reusing the ID is intended, or decide what should happen instead (reject the ID while the deleted record exists, or tie attempts to one incarnation of a destination).
  • Add the table above to the docs (destinations or event delivery page).
Dominant language
Go
Stars
1.1k
Forks
70
Avg merge
1d 18h
Merged PRs (30d)
56

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hookdeck/outpost

All issues in hookdeck/outpost

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.