JobArgs is an interface that represents the arguments for a job of type T. These arguments are serialized into JSON and stored in the database. The struct is serialized using `encoding/json`. All exported fields are serialized, unless skipped with a struct field tag.
| 19 | // The struct is serialized using `encoding/json`. All exported fields are |
| 20 | // serialized, unless skipped with a struct field tag. |
| 21 | type JobArgs interface { |
| 22 | // Kind is a string that uniquely identifies the type of job. This must be |
| 23 | // provided on your job arguments struct. Jobs are identified by a string |
| 24 | // instead of being based on type names so that previously inserted jobs |
| 25 | // can be worked across deploys even if job/worker types are renamed. |
| 26 | // |
| 27 | // Kinds should be formatted without spaces like `my_custom_job`, |
| 28 | // `mycustomjob`, or `my-custom-job`. Many special characters like colons, |
| 29 | // dots, hyphens, and underscores are allowed, but those like spaces and |
| 30 | // commas, which would interfere with UI functionality, are invalid. |
| 31 | // |
| 32 | // After initially deploying a job, it's generally not safe to rename its |
| 33 | // kind (unless the database is completely empty) because River won't know |
| 34 | // which worker should work the old kind. Job kinds can be renamed safely |
| 35 | // over multiple deploys using the JobArgsWithKindAliases interface. |
| 36 | Kind() string |
| 37 | } |
| 38 | |
| 39 | // JobArgsWithKindAliases is an interface that jobs args can implement to |
| 40 | // provide an alternate kind which a worker will be registered under in addition |
nothing calls this directly
no outgoing calls
no test coverage detected
searching dependent graphs…