Change Details

If a job class uses removeDuplicates=true and root job A1 exists and A2 is enqueued, then A2 enqueue becomes a no-op. At the same time, the A1 job is considered as "superceded by a new job" and is no-oped upon being run. A similar problem can happen with the sub-jobs from these root jobs if they also use removeDuplicates=true. Maybe jobs with root timestamps should flip the "oldest job wins" logic to "newest job wins" for per-job deduplication.

If a job class uses removeDuplicates=true and root job A1 exists and A2 is enqueued, then A2 enqueue becomes a no-op. At the same time, the A1 job is considered as "superceded by a new job" and is no-oped upon being run. A similar problem can happen with the sub-jobs from these root jobs if they also use removeDuplicates=true. Maybe jobs with root timestamps should flip the "oldest job wins" logic to "newest job wins" for per-job deduplication. A simpler option is to just not update the "latest root job timestamp" registry if no job was actually inserted (due to removeDuplicates). The later option retains the normal removeDuplicates behavior.

If a job class uses removeDuplicates=true and root job A1 exists and A2 is enqueued, then A2 enqueue becomes a no-op. At the same time, the A1 job is considered as "superceded by a new job" and is no-oped upon being run. A similar problem can happen with the sub-jobs from these root jobs if they also use removeDuplicates=true. Maybe jobs with root timestamps should flip the "oldest job wins" logic to "newest job wins" for per-job deduplication. A simpler option is to just not update the "latest root job timestamp" registry if no job was actually inserted (due to removeDuplicates). The later option retains the normal removeDuplicates behavior.