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

Inconsistency in foreign key when inserting entry in scheduler_changes table #3021

Closed
mthalmei opened this Issue Mar 10, 2017 · 1 comment

Comments

Projects
None yet
3 participants
@mthalmei
Contributor

mthalmei commented Mar 10, 2017

The trac ticket http://trac.buildbot.net/ticket/3532 already adresses a problem when inserting entries into scheduler_changes table.

Although this issue is fixed for SingleBranchScheduler it seems to be still unfixed for the Nightlyscheduler we are using and still getting the same errors.

This ticket is a migrated Trac ticket 3660

@wstering

This comment has been minimized.

Show comment
Hide comment
@wstering

wstering Mar 31, 2017

PostgreSQL 9.4 shows the following error, when processing a change for the NightlyScheduler:

ERROR:  insert or update on table "scheduler_changes" violates foreign key constraint "scheduler_changes_schedulerid_fkey"
DETAIL:  Key (schedulerid)=(18) is not present in table "schedulers".
STATEMENT:  INSERT INTO scheduler_changes (schedulerid, changeid, important) VALUES (18, 721, 1)

Picking up changes works OK for SingleBranchScheduler, as noted above.

wstering commented Mar 31, 2017

PostgreSQL 9.4 shows the following error, when processing a change for the NightlyScheduler:

ERROR:  insert or update on table "scheduler_changes" violates foreign key constraint "scheduler_changes_schedulerid_fkey"
DETAIL:  Key (schedulerid)=(18) is not present in table "schedulers".
STATEMENT:  INSERT INTO scheduler_changes (schedulerid, changeid, important) VALUES (18, 721, 1)

Picking up changes works OK for SingleBranchScheduler, as noted above.

tardyp added a commit to tardyp/buildbot that referenced this issue Mar 31, 2017

Nightly: use serviceid instead of objectid for classification
fixes buildbot#3021

serviceid is pointing to the schedulerid, and is the id required for classification, while objectid is for the state table
this is the same fix as http://trac.buildbot.net/ticket/3532.
I did grep for other use of xxxChangeClassifications to find the same bug class, but it seems nightly is the only remaining

@tardyp tardyp closed this in #3090 Apr 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment