FederatedStore graphIds swapping in ViewValidation error message
See original GitHub issueclass: FederatedOperationChainValidator
line: ~122
Why is the order of graphIds changing in the error message?
This is found in Test FederatedStoreTest
line ~1349 with the regex for graph Order.
// Code smell this has been added because the exception message changes the order of graphs.
When found is the issue localised just to this test? Fix as required.
Issue Analytics
- State:
- Created a year ago
- Comments:11 (11 by maintainers)
Top Results From Across the Web
ArcGIS Portal : Federated server - "failed to vali...
Suddenly we are having trouble with our Relational Datastore on ArcGIS Enterprise 10.5.. If you validate the Hosting server in Portal you ...
Read more >Validation layer Errors when creating swap chain ...
vkCreateSwapchainKHR returns VK_SUCCESS. I am getting validation errors when running vkCreateSwapchainKHR even though the call in itself ...
Read more >You see validation errors for users in the Office 365 portal or in ...
To see which users are affected and the detailed error message, filter the list of users by Users with errors, select a user,...
Read more >Troubleshooting SAML - GitLab Docs
These errors all come from a similar place, the SAML certificate. SAML requests must be validated using either a fingerprint, a certificate, or...
Read more >Vulkan validation errors states my images are in the wrong ...
Outside of specific circumstances or explicit synchronization, operations on the GPU execute in an arbitrary order. Your graphics submission ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think the cache implementation is unordered, and the way the streams work means they will come back in an unreliable order. I presume it always worked like this, or some of the streaming code has changed. Maybe should double check this was always the case
Closed by https://github.com/gchq/Gaffer/pull/2828