Failed to run the handler: (psycopg2.errors.InvalidTextRepresentation) invalid input value for en... #2631
Assignees
Comments
This was referenced Nov 12, 2024
softwarefactory-project-zuul bot
added a commit
that referenced
this issue
Nov 12, 2024
fix(tf): add enum value for requested cancel As @lbarcziova noticed there are some visible spikes of usage in the postgres pod and also a flood of Sentry issues related to the non-existing ‹cancel_requested› TF result in the DB. As it turns out, we receive ‹cancel-requested› from the Testing Farm, but at the same time SQLAlchemy has its own intelligence to use the enum »NAME« instead of the »VALUE« even though it is perfectly usable. SQLAlchemy docs: https://docs.sqlalchemy.org/en/20/core/type_basics.html#sqlalchemy.types.Enum Excerpt in question: Above, the string names of each element, e.g. “one”, “two”, “three”, are persisted to the database. Additionally, for the integrity of the database, the only allowed action on the enums is »adding« the values, so… We can have 2 different cancel states even though only one will be used. This could be potentially cleaned up afterwards after this issue is resolved and it has been verified it's possible to reset the entries (there is no guarantee of the same integer ID being assigned to the same constant…) Although enum types are primarily intended for static sets of values, there is support for adding new values to an existing enum type, and for renaming values (see ALTER TYPE). Existing values cannot be removed from an enum type, nor can the sort ordering of such values be changed, short of dropping and re-creating the enum type. Fixes #2631 Reviewed-by: Laura Barcziová
mfocko
added a commit
that referenced
this issue
Nov 12, 2024
As @lbarcziova noticed there are some visible spikes of usage in the postgres pod and also a flood of Sentry issues related to the non-existing ‹cancel_requested› TF result in the DB. As it turns out, we receive ‹cancel-requested› from the Testing Farm, but at the same time SQLAlchemy has its own intelligence to use the enum »NAME« instead of the »VALUE« even though it is perfectly usable. SQLAlchemy docs: https://docs.sqlalchemy.org/en/20/core/type_basics.html#sqlalchemy.types.Enum Excerpt in question: Above, the string names of each element, e.g. “one”, “two”, “three”, are persisted to the database. Additionally, for the integrity of the database, the only allowed action on the enums is »adding« the values, so… We can have 2 different cancel states even though only one will be used. This could be potentially cleaned up afterwards after this issue is resolved and it has been verified it's possible to reset the entries (there is no guarantee of the same integer ID being assigned to the same constant…) Although enum types are primarily intended for static sets of values, there is support for adding new values to an existing enum type, and for renaming values (see ALTER TYPE). Existing values cannot be removed from an enum type, nor can the sort ordering of such values be changed, short of dropping and re-creating the enum type. Fixes #2631 Co-authored-by: Laura Barcziová <[email protected]> Signed-off-by: Matej Focko <[email protected]> (cherry picked from commit b41fb97)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sentry Issue: PCKT-002-PACKIT-SERVICE-8VB
The text was updated successfully, but these errors were encountered: