Open aali309 opened 1 month ago
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?
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?
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.
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.
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 doSTOPPED
andNEVER
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.
@aali309 how is the testing this issue? Is this persistent and only for replace: ALWAYS
?
@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.
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"
}
}
}
]
}
}
Current Behavior
Expected Behavior
Active Recordings should update to reflect the create recording notification.
Steps To Reproduce
localhost:8080
Recordings
tableEnvironment
Anything else?
No response