Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • S Storage
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 52
    • Issues 52
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 16
    • Merge requests 16
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Open Subsurface Data Universe SoftwareOpen Subsurface Data Universe Software
  • Platform
  • System
  • Storage
  • Issues
  • #97
Closed
Open
Issue created Nov 01, 2021 by Alok Joshi@ajoshi19Owner

Storage createOrUpdateRecord api fails with 500 if too many versions of the same recordId are created

We've been observing this issue where users try to create too many versions of the same recordId. The versions are stored as part of the record metadata in CosmosDb (StorageRecord table). When the metadata reaches a size limit (around 2MB), adding more versions to the list fails.

This failure in CosmosDb operation is returned as an internal server error (500) from Storage. This should rather be a 4xx (413 Request too large) exception.

Changes proposed:

  • Catch RequestEntityTooLargeException explicitly in core-lib-azure https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/blob/master/src/main/java/org/opengroup/osdu/azure/cosmosdb/CosmosStore.java#L522
  • Gracefully handle the exception from core-lib-azure in Storage, instead of always throwing a 500 https://community.opengroup.org/osdu/platform/system/storage/-/blob/master/storage-core/src/main/java/org/opengroup/osdu/storage/service/PersistenceServiceImpl.java#L132
Assignee
Assign to
Time tracking