git repository setRule() triggers Internal Server Error following an Assert
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
High
|
Colin Watson | ||
Bug Description
When updating the rules applied to a git repository the setRules call is triggering a Internal Server Error following an Assert in launchpad:
AssertionError: setRules failed to establish requested rule order [u'refs/
Full OOPS:
https:/
We are attempting to change the rules on https:/
- grants:
- can_create: false
can_
can_push: true
grantee_link: https:/
grantee_type: Person
ref_pattern: refs/heads/*
- grants:
- can_create: true
can_
can_push: false
grantee_link: https:/
grantee_type: Person
ref_pattern: refs/tags/*
- grants:
- can_create: true
can_
can_push: true
grantee_link: https:/
grantee_type: Person
- can_create: false
can_
can_push: false
grantee_link: null
grantee_type: Repository owner
ref_pattern: '*'
to:
- grants:
- can_create: true
can_
can_push: false
grantee_link: /~canonical-
grantee_type: Person
ref_pattern: refs/heads/
- grants:
- can_create: true
can_
can_push: false
grantee_link: /~canonical-
grantee_type: Person
ref_pattern: refs/heads/master
- grants: &id001
- can_create: true
can_
can_push: false
grantee_link: /~canonical-
grantee_type: Person
ref_pattern: refs/tags/
- grants: *id001
ref_pattern: refs/tags/v4.18*
- grants:
- can_create: true
can_
can_push: true
grantee_link: /~canonical-
grantee_type: Person
- can_create: false
can_
can_push: false
grantee_link: null
grantee_type: Repository owner
ref_pattern: '*'
Related branches
- William Grant: Approve (code)
-
Diff: 295 lines (+89/-48)5 files modifiedlib/lp/code/interfaces/gitrule.py (+14/-7)
lib/lp/code/model/gitrepository.py (+19/-9)
lib/lp/code/model/gitrule.py (+36/-27)
lib/lp/code/model/tests/test_gitrepository.py (+15/-1)
lib/lp/code/model/tests/test_gitrule.py (+5/-4)
| tags: | added: api git lp-code |
| Changed in launchpad: | |
| status: | New → In Progress |
| importance: | Undecided → High |
| assignee: | nobody → Colin Watson (cjwatson) |
| Colin Watson (cjwatson) wrote | #1 |
| Launchpad QA Bot (lpqabot) wrote | #2 |
| tags: | added: qa-needstesting |
| Changed in launchpad: | |
| status: | In Progress → Fix Committed |
| tags: |
added: qa-ok removed: qa-needstesting |
| Changed in launchpad: | |
| status: | Fix Committed → Fix Released |
It's intended that rule ordering is canonicalised: exact-match rules first in lexicographical order, followed by wildcard rules in the requested order. (The ordering of exact-match rules relative to each other can't matter, it doesn't make sense for them to follow wildcard rules, and it's helpful in some cases to have a canonical ordering.)
However, I forgot to canonicalise the expected ordering in setRules as well, so the end result is (in part) an assertion that the webservice API caller provided the rules in canonical order, which of course isn't appropriate.