Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

_JobStatus is an internal collection and therefore not supposed to be used for anything else than supporting features of Parse Server. Any change to that collection would not constitute a breaking change, so one can not rely on it, what is logged, how it's logged, or whether anything is logged at all.

In that context, the params stored cannot have any operational value, they could have at most analytical or troubleshooting value. In addition, storing operational data in an internal collection is not supposed to happen and we should probably implement a guideline for reviewers about that. Operational data may be sensitive, require data protection considerations, auditing, or other things that are problematic for internal collections.

My suggestion is to remove param logging. If params are currently used by Parse Server, then we could think about finding a replacement concept. Any logging of params can be implemented fine-grained and according to use case by the developer in the job script itself.

@mtrezza So if I understand you correctly, you think we should remove the params altogether?

I would say so, unless there is a good reason why they are logged. Did you look at the code to see whether they are used anywhere?

The only good reason to store the params in the JobStatus document would be to have a retry mechanism of some sort. But as of today these params does not seem to be used anywhere.

Good to know that they aren't used. So I'd suggest to remove then completely.

If I understood the discussion correctly, the solution would be to keep this file in a separate location like a ParseFile, for example. So it would only be necessary to pass an objectId as a Job parameter.

Although today the parameters are not shown on the Job Status page, I would prefer not to remove them, as simply removing them does not improve privacy or security at all.

I've also thought about the possibility of making a retry mechanism, but I never had the time.
So, if you still want to remove something... Please, just remove it from the collection, because I have several Jobs using parameters and I believe that there are many more users who also use them.

Please disregard the comment, if I understood something wrong or if I didn't express myself well, because English is not my main language.

If I understood the discussion correctly, the solution would be to keep this file in a separate location like a ParseFile, for example. So it would only be necessary to pass an objectId as a Job parameter.

Although today the parameters are not shown on the Job Status page, I would prefer not to remove them, as simply removing them does not improve privacy or security at all.

I've also thought about the possibility of making a retry mechanism, but I never had the time. So, if you still want to remove something... Please, just remove it from the collection, because I have several Jobs using parameters and I believe that there are many more users who also use them.

Please disregard the comment, if I understood something wrong or if I didn't express myself well, because English is not my main language.

The params are only removed from the collection, they are still passed through the request to the Parse.Job function so no worries about that.

@danielsanfr did that answer address your concerns?

🎉 This change has been released in version 8.2.1-alpha.2

🎉 This change has been released in version 8.2.1