Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
erp5 erp5
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Labels
    • Labels
  • Merge requests 140
    • Merge requests 140
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Jobs
  • Commits
Collapse sidebar
  • nexedi
  • erp5erp5
  • Merge requests
  • !1882

Merged
Created Feb 21, 2024 by Jérome Perrin@jeromeOwner

Fix code depending on python2 __hash__

  • Overview 14
  • Commits 41
  • Pipelines 24
  • Changes 125

With python2, iterating on a dictionary or a set always produces the same result, although this is not a documented behavior. On python3 this is not the case, because the hashing algorithm is random by default, which can also be set using PYTHONHASHSEED. On SlapOS, this is done with slapos!1535 (merged)

This fixes the parts where ERP5 code depends on python2 order, mostly tests, but also places where we iterate on a dictionary or set. Most of the time, the fix has been to sort so that the order is deterministic regardless of the hash algorithm randomization, but sometimes we had to extend a bit the configuration where the order was really important. We did this after discovering the problematic areas by running tests multiple times with different hash randomization seeds. It's not impossible that changing from "default python2 order" to "sorted" reveals some more problems in custom configurations, but this would mean that the configuration must be adjusted to use explicit order instead of being lucky with the default python2 order.

The main pattern was the use of edit method which edits properties in an order that is a bit constrained with the edit_order mechanism, because some properties depend on other properties, so it's important to set them in order. This extends a bit the edit_order mechanism to specify more properties that were edited in the right order with PYTHONHASHSEED=0 by chance.

This also extends delivery builders to edit properties in order defined in the equivalence tester, most equivalence tester were already properly configured, except the start_date and stop_date from delivery level movement groups. That probably only matters for some specific test assertions, but in practice this was visible in a lot of failing tests.

Some visible changes are that:

  • workflows are now sorted alphabetically on history tab
  • properties are now sorted alphabetically on the diff view of history tab
  • business templates are installed in the order of dependencies and in alphabetic order when they are not constrained.
Edited Mar 06, 2024 by Jérome Perrin
Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: fix/hashseed
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7