Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Active Recordings table fails to update when restarting a recording with replace: ALWAYS #1286

Open
aali309 opened this issue Jun 14, 2024 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@aali309
Copy link
Contributor

aali309 commented Jun 14, 2024

Current Behavior

Screenshot from 2024-06-14 13-06-42

Expected Behavior

Active Recordings should update to reflect the create recording notification.

Steps To Reproduce

  1. checkout on cryostatio/cryostat main branch
  2. build and run smoketest
  3. visit localhost:8080
  4. navigate to Recordings table
  5. run the below query on terminal and see the behavior on the web UI
`http --follow -v --auth='user:pass' POST :8080/api/v3/graphql \
      Content-Type:application/json \
      query='
  query {
    targetNodes(filter: { annotations: ["PORT = 9091"] }) {
      name
      target {
        doStartRecording(recording: {
          name: "test",
          template: "Profiling",
          templateType: "TARGET",
          replace: "ALWAYS"
        }) {
          name
          state
        }
      }
    }
  }'

Environment

- OS: 
- Environment: 
- Version:

Anything else?

No response

@aali309 aali309 added bug Something isn't working needs-triage Needs thorough attention from code reviewers and removed needs-triage Needs thorough attention from code reviewers labels Jun 14, 2024
@aali309 aali309 changed the title [Bug] <ActiveRecording Table>: Active Recordings table fails to update when restarting a recording with replace: ALWAYS [Bug] Active Recordings table fails to update when restarting a recording with replace: ALWAYS Jun 14, 2024
@andrewazores
Copy link
Member

This is just a notification handling issue, right? If I understand correctly, the notification appears but the table does not update. If you navigate away and back, or refresh, the table contains the correct new content?

@andrewazores
Copy link
Member

Please also check for any other similar cases with this view/table not updating. It sounds like the particular query you used to perform the update would not be the only way to trigger this behaviour. Like, is the replace: ALWAYS the only time it breaks, or do STOPPED and NEVER do it too?

@tthvo
Copy link
Member

tthvo commented Jun 14, 2024

I did a quick test locally and the behaviour is correct with the notification updating the table. Might just be another issue with flanky notification handling.

image

@aali309
Copy link
Contributor Author

aali309 commented Jun 14, 2024

This is just a notification handling issue, right? If I understand correctly, the notification appears but the table does not update. If you navigate away and back, or refresh, the table contains the correct new content?

Yes, just like what was happening with the Archived tables before and labels.

@aali309
Copy link
Contributor Author

aali309 commented Jun 14, 2024

Please also check for any other similar cases with this view/table not updating. It sounds like the particular query you used to perform the update would not be the only way to trigger this behaviour. Like, is the replace: ALWAYS the only time it breaks, or do STOPPED and NEVER do it too?

These are my next tests. I will be looking for those and similar, like 'restart: true'. I saw Stopping an Active recoding updates as expected.

@tthvo
Copy link
Member

tthvo commented Jun 17, 2024

@aali309 how is the testing this issue? Is this persistent and only for replace: ALWAYS?

@aali309
Copy link
Contributor Author

aali309 commented Jun 18, 2024

@aali309 how is the testing this issue? Is this persistent and only for replace: ALWAYS?

So far, for replace:NEVER works as expected for all scenarios and recordings.

replace:ALWAYS and
replace:STOPPED on the already exist recordings (i.e startup and onstart) works as expected. The table updates and the right notification is emitted.
image

However, on newly created recordings (i.e test, test2 etc), the table does not update until page is refreshed or navigating away and back, and different notification is emitted compared to the above. (So only newly created recordings have this issue but not the existing ones (i.e startup and onstart).
The query and response works well the only issue is on the UI (different notification and updating the table).

❯ http --follow -v --auth='user:pass' POST :8080/api/v3/graphql \
      Content-Type:application/json \
      query='
  query {
    targetNodes(filter: { annotations: ["PORT = 9091"] }) {
      name
      target {
        doStartRecording(recording: {
          name: "test", # could cnange the name of the recording to see different results
          template: "Profiling",
          templateType: "TARGET",
          replace: "STOPPED" # you can replace this with "ALWAYS"
        }) {
          name
          state
        }
      }
    }
  }'

POST /api/v3/graphql HTTP/1.1
Accept: application/json, */*;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic dXNlcjpwYXNz
Connection: keep-alive
Content-Length: 333
Content-Type: application/json
Host: localhost:8080
User-Agent: HTTPie/3.2.2

{
    "query": "\nquery {\n  targetNodes(filter: { annotations: [\"PORT = 9091\"] }) {\n    name\n    target {\n      doStartRecording(recording: {\n        name: \"test\",\n        template: \"Profiling\",\n        templateType: \"TARGET\",\n        replace: \"STOPPED\"\n      }) {\n        name\n        state\n      }\n    }\n  }\n}"
}


HTTP/1.1 200 OK
Content-Length: 153
Content-Type: application/json
Date: Tue, 18 Jun 2024 14:07:37 GMT
Gap-Auth: user

{
    "data": {
        "targetNodes": [
            {
                "name": "service:jmx:rmi:///jndi/rmi://cryostat3:9091/jmxrmi",
                "target": {
                    "doStartRecording": {
                        "name": "test",
                        "state": "RUNNING"
                    }
                }
            }
        ]
    }
}

image

@andrewazores andrewazores moved this to Backlog in 4.0.0 release Jul 9, 2024
@Josh-Matsuoka Josh-Matsuoka self-assigned this Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Backlog
Development

No branches or pull requests

4 participants