259 write tests to validate reliability features eg simulated network failures retries e3 #284
Conversation
…y if the CI is successful
…y if the CI is successful
…y if the CI is successful
…y if the CI is successful
…y if the CI is successful
…e-reliability-features-eg-simulated-network-failures-retries-e3
src/tests/test.rs
Outdated
| use tokio::time::{sleep, Duration}; | ||
| use tokio::sync::{futures, Mutex}; | ||
| use uuid::Uuid; |
There was a problem hiding this comment.
Regarding the imports to your test module, I do not seem to understand what you will be testing. Can you help me answer that? I'm not being rhetoric, it's a genuine question.
There was a problem hiding this comment.
I'm kinda testing a lot of things, Some which I am testing now and others for later. Please just check my documentation 🙏 Reliability Features doc
There was a problem hiding this comment.
Great that you're testing a lot of things. Please enlighten me on one of them. Let us consider the test with the description "Validate retry mechanism under network interruptions." I have two questions:
- Which entity in the test is subject to network interruptions that would prevent access to it?
- Which entity should implement a retry mechanism under these conditions?
There was a problem hiding this comment.
The entity subject to network interruptions is the DIDComm mediator server itself or any intermediary network-dependent service it relies on (e.g a database or external service). In the context of the test, this would simulate scenarios where:
. The client agent (the test environment) attempts to send a message to the mediator server but experiences timeouts or dropped connections.
. The mediator server itself might lose connectivity to an upstream service (e.g, a cloud-based DID registry).
There was a problem hiding this comment.
The entity that should initiates the communication (retry mechanism) in this case, is the client agent why?. This is because:
The client is responsible for ensuring the message is delivered successfully to the mediator server.
If the server is temporarily unavailable, the client should attempt to resend the message after a delay or a backoff period.
For example, If the client sends a message and receives no acknowledgment from the mediator, the client should retry according to a predefined policy (e.g, exponential backoff).
There was a problem hiding this comment.
You are listing two options:
- The client agent (the test environment) attempts to send a message to the mediator server but experiences timeouts or dropped connections.
- The mediator server itself might lose connectivity to an upstream service (e.g, a cloud-based DID registry).
This ticket is about writing tests to validate reliability features, which basically implies those implemented by the mediator to remain reliable. In the first case, like you said yourself, it is the client implementing reliability features for the situation, not the mediator. And you're not expected to test features you're implementing yourself to simulate the actions of a client.
With that I believe you can discard Option 1 and focus on Option 2, so the actual reliability features assumed implemented by the mediator are tested. What do you think?
There was a problem hiding this comment.
Sure. Thanks for this enlightenment 👍
I think I'm good to go now
There was a problem hiding this comment.
Please hold on with the review, I'm still tryna fix my tests, I should be done by the end of the day.
…ulated-network-failures-retries-e3' of github.com:adorsys/didcomm-mediator-rs into 259-write-tests-to-validate-reliability-features-eg-simulated-network-failures-retries-e3
In
CI.yml:. Added a separate
reliability-testsjob to isolate tests for retry logic and acknowledgment.. Used the
--filter reliabilityflag in thecargo nextest runcommand to run only the reliability-related tests.. Cached the
target/cargo-nextestdirectory to speed up future runs.In
CD.yml:. Added a trigger (
on.workflow_run) to ensure deployment only happens after theCIworkflow completes successfully.. Added an
ifcondition to proceed with deployment only if theCIworkflow's conclusion issuccess.