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
  • !235

Merged
Created Feb 15, 2017 by Jérome Perrin@jeromeOwner

Lower priority of mass workflow transition activity

  • Overview 1
  • Commits 1
  • Changes 1

We had an incident in a in instance were a user changed state of 70K invoices using https://www.erp5.com/howto/erp5-developer-howto/erp5-HowTo.Change.Workflow.State.Of.Multiple.Documents and leads to user not receiving the reports they requested.

Folder_modifyWorkflowStatus creates a lot of callMethodOnObjectList activities (for all the selected documents) with priority 2, then these activities will cause more reindex an expand activities.

Until all these callMethodOnObjectList are processed, no new activities with priority > 2 were processed. Some "important for users" activities such as erp5_deferred_style reports where waiting in the queue.

I believe we should just set a lower priority to these callMethodOnObjectList, eventhough I considered a more clever way of giving the priority:

  • if the number of selected documents is reasonably small, process them with a very high priority, this way the user can see his document changing state almost immediately as when using the synchronous change state. This should not cause congestion because there are not too many documents.
  • when there are a lot of selected documents, process them with a very low priority, because anyway it will take time and user will not "wait" for documents to change state.

... but I realized this is trying to be too clever.

So any objections to just lower priority here ?

Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: fix/change_state_priority
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7