Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Date transformed into string when queued #2771

Open
1 task done
Holbanner opened this issue Sep 16, 2024 · 4 comments
Open
1 task done

[Bug]: Date transformed into string when queued #2771

Holbanner opened this issue Sep 16, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@Holbanner
Copy link

Version

v5.8.2

Platform

NodeJS

What happened?

When adding an object with a key typed as a date in following format : 2024-09-13T15:00:00.000Z the worker gets it back as a string, logicaly loosing all date methods

How to reproduce.

Add an item with at least one js date key to the queue, then check the date in a worker. It is now a string

Relevant log output

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@Holbanner Holbanner added the bug Something isn't working label Sep 16, 2024
@manast
Copy link
Contributor

manast commented Sep 16, 2024

Yeah, this is the way JSON.stringify/parse works. We would need another serialisation scheme to support dates.

@manast manast added enhancement New feature or request and removed bug Something isn't working labels Sep 16, 2024
@Holbanner
Copy link
Author

So the "proper" way to deal with this would be to rebuild the dates in the workers?

@manast
Copy link
Contributor

manast commented Sep 16, 2024

Yes, you need to recreate the date objects when you need them.

@bredar
Copy link

bredar commented Oct 8, 2024

We are facing similar problems using date objects in our jobs. A nice solution could be to use superjson (https://github.com/flightcontrolhq/superjson) (or similar) to serialize and deserialize job data. This would automatically handle date objects and also bigint (#447) or map.
I think it should not be very difficult to implement. For us, as we use a lot of workers, it would be helpful to have a global option to always use superjson for all jobs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants