What is the relation between queue-name and task/job payload type?

[kirillsalykin]

I might be overlooking something, but I am currious how those are related? is it 1 to 1? can WelcomeEmail appear in different job-queues? Is it needed for the steps?

[maxcountryman]

For tasks specifically (so setting aside the job abstraction for a moment) the input type is tied to the queue in a one-to-one manner, yes. In other words, the named queue should only handle input of that type. You can extend this somewhat to support multiple tasks through more complex input types (the multitask example demonstrates this).

This is true of jobs as well but jobs work by wrapping a serde_json::Value (see the job input type construction). So each step has its own input type and it must be deserialized to whatever that input is. Internally this is stored as a Value. Even so, we get compile time input type safety thanks to the job builder.

All that said, our type safety can only extend to the surface of the application: if something were to interfere with what's actually stored by Postgres or we change the application-level types, stored data can become corrupted. (Versioning tasks or jobs could help a bit here, but doesn't entirely address misuse.)

[kirillsalykin]

so, if it 1-1 - does it make sense to use type name as a job-queue by default?
eg WelcomeEmail?

[maxcountryman]

As in to infer the queue name from the input type name?

Possibly, although the facility for actually determining the input name as a string in Rust seems a bit challenging (I looked at std::any a bit and it didn't seem like it was the right approach).

Another reason this might not be desirable is that right now if I change my application code and I have outstanding jobs in Postgres there's a bit of a problem: my outstanding jobs will break if I'm not careful (if my input type is not backwards compatible). One way around this is to change the queue name (it's possible to then run the old tasks alongside the new tasks).

[maxcountryman]

Sorry I'm also wrong when I say "one-to-one". For example, consider when the input type is unit (actually not too uncommon for me to write a task that doesn't take input directly and just runs a side effect, especially for scheduled use cases): in this case, there's a specific queue that the task belongs to but there can be any number of queues that manage tasks with a unit input type. So in that case the queue name is the way we refer to the queuing of the specific task. Hope that makes things clearer.

[kirillsalykin]

if it is not 1-1 - then no questions :)