Details
- Kill app after decrypting but before processing (adding sleep)
- Open and make sure message is processed
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| lib/tunnelbroker/peer-to-peer-message-handler.js | ||
|---|---|---|
| 42–44 ↗ | (On Diff #43379) | 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 ↗ | (On Diff #43379) | 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 ↗ | (On Diff #43379) | 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 ↗ | (On Diff #43379) | 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 ↗ | (On Diff #43379) | 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 ↗ | (On Diff #43379) | LOG_OUT_PRIMARY_DEVICE - we're about to delete the database anyway |
| lib/tunnelbroker/use-peer-to-peer-message-handler.js | ||
|---|---|---|
| 119–148 ↗ | (On Diff #43379) | I wonder if this could be documented in the code via code comments |