Details
- Kill app after decrypting but before processing (adding sleep)
- Open and make sure message is processed
Diff Detail
- Repository
- rCOMM Comm
- Branch
- resending-4
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| lib/tunnelbroker/peer-to-peer-message-handler.js | ||
|---|---|---|
| 42–44 | I'm wondering if we could encode these two booleans into some state variables, e.g. BEFORE_INBOUND_MESSAGES_PROCESSING | INBOUND_MESSAGES_PROCESSING | WAITING_FOR_A_MESSAGE | PROCESSING_A_MESSAGE | |
| 98 | Why do we have to process them on app start? Do we assume that some messages could be in the middle of processing when the app got closed? | |
| lib/tunnelbroker/use-peer-to-peer-message-handler.js | ||
| 119–148 | Why do we have to remove the messages? Why are we doing this only in these two places? | |
| lib/tunnelbroker/peer-to-peer-message-handler.js | ||
|---|---|---|
| 42–44 | I think this approach is a bit more readable because processing inbound messages on app start and processing received messages are two different things | |
| 98 | This is to handle cases when the app was killed after decrypting but before processing - we can decrypt the message only once, so in one transaction we decrypt and save the Inbound message. That saves us from losing data. | |
| lib/tunnelbroker/use-peer-to-peer-message-handler.js | ||
| 119–148 | LOG_OUT_PRIMARY_DEVICE - we're about to delete the database anyway | |
| lib/tunnelbroker/use-peer-to-peer-message-handler.js | ||
|---|---|---|
| 119–148 | I wonder if this could be documented in the code via code comments | |