There is no reason to raise an error when a task type has already been created and it enables to stop leaking
psycopg2 IntegrityError exception as part of the scheduler interface.
Details
- Reviewers
vlorentz olasd - Group Reviewers
Reviewers - Commits
- rDSCHaf58466e6ec3: backend: Make create_task_type idempotent
Diff Detail
- Repository
- rDSCH Scheduling utilities
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
Build is green
See https://jenkins.softwareheritage.org/job/DSCH/job/tox/348/ for more details.
Instead of doing this, I think we should really make create_task_type idempotent. Looks like no users of this API actually depend on the "fail if type already exists" behavior.
If we do that, we'll stop leaking psycopg2 IntegrityErrors as part of the scheduler interface, which is, er, gross.
Update: make create_task_type idempotent instead of raising an exception when a task type has already been created.
Build has FAILED
Link to build: https://jenkins.softwareheritage.org/job/DSCH/job/tox/349/
See console output for more information: https://jenkins.softwareheritage.org/job/DSCH/job/tox/349/console
swh/scheduler/backend.py | ||
---|---|---|
102 | Wouldn't it make more to do update? |
Build is green
See https://jenkins.softwareheritage.org/job/DSCH/job/tox/350/ for more details.
swh/scheduler/backend.py | ||
---|---|---|
102 | I'd rather have policy updates be a manual operation, so ack for on conflict do nothing. |
But then, errors would pass silently...
If the issue is only leaking the postgresql exception, we could catch it and reraise another one.