1. Does the retry function work based on the logic that the same input will always return the same output, even if the code uses non-deterministic methods like "new Date()" or "Math.random"? If not, your retry logic may produce unpredictable results and therefore not be safe.
2. According to the article "How Defer Works" (https://docs.defer.run/platform/how-defer-works/), you will be running our code on your platform. How do you ensure the protection of sensitive data during the execution process? For example, how will you prevent access tokens or user/password information for the database from showing up in logs due to exceptions or bad configurations?
1. Yes, we currently provide a simple approach to retries but are already working on providing features for idempotency.
2. All sensitive data (tokens, env vars) are encrypted on our side, however, we don't prevent users to print their values in the logs yet - it's planned in our next releases.
I see. I hope you have a great journey. I used to want to implement a system like that for my import/export tasks because my workload heavily involves importing and exporting CSV files. But the deadline defeated me ;) I have no time to design a system like that
By the way, I really love how simple the defer API is to use
1. Does the retry function work based on the logic that the same input will always return the same output, even if the code uses non-deterministic methods like "new Date()" or "Math.random"? If not, your retry logic may produce unpredictable results and therefore not be safe.
2. According to the article "How Defer Works" (https://docs.defer.run/platform/how-defer-works/), you will be running our code on your platform. How do you ensure the protection of sensitive data during the execution process? For example, how will you prevent access tokens or user/password information for the database from showing up in logs due to exceptions or bad configurations?