fixthestatusquo / fixthestatusquo/proca-server
Trust microservice - confirm reminder service
- Dominant language
- Elixir
- Stars
- 11
- Forks
- 13
- Avg merge
- 6d 14h
- Merged PRs (30d)
- 2
Description
- [ ] Add state to the microservice - we can use [LevelDB](https://leveljs.org/) ([doc](https://github.com/Level/level)) for nodejs (or sqlite?)
- [ ] listen on custom supporter confirm queue (eq [cus.4.confirm.supporter]). On message, store at key action-${actionId} the whole action message. Before it, check if it already exists or if done-${actionId} exists, and if so (repeated message) don't do anything. Also store retry-${actionId} the timestamp of next retry ( action.insertedAt + 3 days for example) as well as number of the retry (we have 1st and second retry, possibly more to configure)
- [ ] Listen on additional delivery queue too (the original delivery queue is used for sync , we can make a copy eg delivery_repeater) When delivery happens, mark the record as confirmed (remove the key action-${actionId}, remove schedule key retry-${actionId} and create a key done=${actionId} = true so we know this aciton was processed.
- [ ] Create a cron job, which iterates over the level db and checks which actions need repeating - check all the keys for retry-1234 keys and check if the date is in the past - means we should repeat the action. To do this, re-insert it into the confirmation queue, and under retry-${actionId} store the date and number of next retry. If we reached maximum retries, store "never" or other special keyword. Innserting the confirm message again into the rabbitmq queue for sending emails [exchange: "", routing key: wrk.${orgId}.email.supporter]. Please add a `action.fields.reminder=true`
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.