Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • GraceDB Server GraceDB Server
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 75
    • Issues 75
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 6
    • Merge requests 6
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • IGWN Computing and Software
  • GraceDB
  • GraceDB ServerGraceDB Server
  • Issues
  • #7
Closed
Open
Created Jun 13, 2018 by Leo P. Singer@leo-singerContributor

Superevent 'new' and 'update' LVAlert messages have inconsistent structure

The new and update LVAlert messages have very different structures. For the new message, the uid is the GraceDb ID of the superevent, whereas for the update message the did is the GraceDb ID of the subevent.

In fact, the update messages do not even contain the superevent ID in a machine-friendly field; it is only present in the English comment field (e.g. Set as preferred event for superevent: S180613bw).

It would make it easier to deal with this LVAlert messages if they shared the same structure: the superevent ID and the preferred event ID should always be found in the same machine-friendly fields.

New superevent

{
    "object": {
        "superevent_id": "S180613bw",
        "created": "2018-06-13 17:53:37 UTC",
        "submitter": "emfollow",
        "preferred_event": "M3404",
        "t_start": 1212947423.09,
        "t_0": 1212947433.09,
        "t_end": 1212947443.09,
        "gw_events": [
            "M3404"
        ],
        "em_events": [

        ],
        "labels": [

        ],
        "links": {
            "files": "/apibasic/superevents/S180613bw/files/",
            "logs": "/apibasic/superevents/S180613bw/logs/",
            "self": "/apibasic/superevents/S180613bw/",
            "labels": "/apibasic/superevents/S180613bw/labels/",
            "voevents": "/apibasic/superevents/S180613bw/voevents/",
            "emobservations": "/apibasic/superevents/S180613bw/emobservations/",
            "events": "/apibasic/superevents/S180613bw/events/"
        }
    },
    "uid": "S180613bw",
    "labels": [

    ],
    "alert_type": "new",
    "file": "",
    "description": "NEW: superevent S180613bw"
}

Updated superevent

{
    "object": {
        "comment": "Set as preferred event for superevent: S180613bw",
        "file_version": null,
        "tag_names": [

        ],
        "file": null,
        "created": "2018-06-13T17:53:37.431668+00:00",
        "self": null,
        "issuer": "emfollow",
        "filename": "",
        "tags": null,
        "N": 6
    },
    "uid": "M3404",
    "labels": [

    ],
    "alert_type": "update",
    "file": "",
    "description": "LOG: Set as preferred event for superevent: S180613bw"
}

CC @tanner.prestegard.

Edited Jun 13, 2018 by Leo P. Singer
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking