chore: revert the change from yield_now to sleep

[carneiro-cw]

No description provided.

[github-actions]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	2, because the PR involves a straightforward change from using sleep to yield_now in an asynchronous context. The change is localized and affects only one specific behavior in the code.
🧪 Relevant tests	No
⚡ Possible issues	Possible Bug: Replacing sleep with yield_now might not ensure the intended delay. yield_now simply yields execution to the scheduler, potentially allowing other tasks to run, but it does not pause execution for a specific duration like sleep does. This could lead to issues if the delay was critical for functionality or performance.
🔒 Security concerns	No

Code feedback:

---

relevant file	src/bin/importer_online.rs
suggestion	Consider using an asynchronous delay mechanism that ensures a minimum wait time, such as sleep, if the delay is critical for the logic. Replacing sleep with yield_now might lead to unexpected behavior since yield_now does not guarantee any delay. [important]
relevant line	yield_now().await;

---

[github-actions]

PR Code Suggestions ✨

Category	Suggestion	Score
Possible issue	Replace yield_now().await with sleep(INTERVAL_CATCH_UP).await to ensure a consistent delay Replacing yield_now().await with sleep(INTERVAL_CATCH_UP).await might not be equivalent in terms of functionality. yield_now() only yields the current task, allowing others to run, which might not provide a sufficient delay if the system is under low load. This could lead to a tight loop situation. Consider reintroducing a sleep with a defined interval to ensure there is a delay. src/bin/importer_online.rs [299] -yield_now().await; +sleep(INTERVAL_CATCH_UP).await; Suggestion importance[1-10]: 9 Why: The suggestion correctly identifies a potential issue where yield_now().await may not provide a sufficient delay, especially under low system load. Reintroducing sleep(INTERVAL_CATCH_UP).await ensures a consistent delay, preventing a tight loop situation.	9