At this point calling the endpoint results in link being deleted. In the future we can consider having a list of disabled links.
Depends on D7885
Details
Details
Tested in combination with the rest of the stack. Confirming disabling a link results in link being deleted.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| keyserver/src/responders/link-responders.js | ||
|---|---|---|
| 93 | Should this be mixed now? | |
| keyserver/src/deleters/link-deleters.js | ||
|---|---|---|
| 24–27 | Why should we throw? It is generally a good idea to have more idempotent API: in this case, the intention of a user was for a link to not exist. If that's the case, then great - it doesn't matter if a link wasn't existing before. A possible scenario where it could happen is when two users try to disable a link at the same time - it's ok that one of the request will finish earlier. A different corner case is when a link was renamed by one user. Then it's hard to tell how we should handle that. There are a couple of solutions. But that would require some analysis (probably not worth it in the near future). | |
| keyserver/src/deleters/link-deleters.js | ||
|---|---|---|
| 24–27 | Your explanation makes sense. My intention was to point out that when a user calls this endpoint and nothing changes we probably shouldn't allow the user to call it (as this is something unexpected), but from the scenario you brought it looks like a regular situation, sorry for the confusion | |