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
Links in LogEntryCollection are not followed and checked #519
Comments
Edit: Oh, nevermind. It is likely because the validator is not checking the DIRECT call to that odata.id, it is checking it from within the collection without GETting it from the service from it's URI twice (Note the 0ms response time). I believe there's code in place for some URIs checked but not unique URIs like this. This is an assumption from the tool, and needs to be reported correctly. |
Oh I see, in other LogEntryCollection, it also does not follow the link.
I think only not following the links with Anyway I'm going to update the issue. |
Currently getting single PostCode entry returns a LogEntryCollection with the specified LogEntry in its Members. Since Redfish Service Validator does not follow the links in LogServiceCollection[1], such unexpected behavior passes the validator. This commit makes it return the LogEntry itself (or 404 Not Found) when requesting it. Fixes Github issue #236 (#236) [1] DMTF/Redfish-Service-Validator#519 Tested: * Confirmed getting a valid PostCode entry now returns a LogEntry, and getting invalid entries like B0-1, B1-0, B1-999 or 123 (Not properly- formatted ID) responds with 404 Not Found. * Get PostCode log entries collection still returns LogEntryCollection containing first 1000 PostCode entries by default. * Redfish Service Validator passed. Change-Id: Ice6b8742caea96ad3d436d57898202fe7362b150 Signed-off-by: Jiaqing Zhao <jiaqing.zhao@intel.com>
I am also seeing this error. In |
The collection is supposed to be expanded even if not requested; if LogEntryCollection does not show the contents of the LogEntry resources in the Members array, it's nonconformant. |
@blakehilliard to be clear, are you saying the collection is auto expanded and the case is it's treating it like it's not? Do you have a sample of what you're running exactly from the command line? |
Thanks, I was unaware a collection could have thiis auto-expansion requirement. |
To date, we only have that requirement on the LogEntryCollection (with the OData.AutoExpand term specified on the Members NavigationProperty). In theory it could be applied elsewhere, but there hasn't been a need to force expansion like with logs. The service validator dynamically looks for the OData.AutoExpand term to determine whether or not it should expect the expansion in the response (and validates accordingly). |
Version: 2.2.1
Validator only checks the
LogEntry
in the response payload ofLogEntryCollection
, theLogEntry
resourced linked at@odata.id
is not checked. (Response time is 0 and HTTP status is -1)When the
LogEntry
resources at@odata.id
is incorrect, as validator skips them, no error reported.The text was updated successfully, but these errors were encountered: