[
https://issues.apache.org/jira/browse/UNOMI-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1021:
-------------------------------
Description:
h3. In short
When a report is requested by an unsupported time period, for example "every 2
days", Unomi returns an empty answer instead of saying the request is wrong.
The person or application asking cannot tell what went wrong, and the problem
only shows up in the server logs.
h3. Summary
A date aggregate accepts the short interval forms ({{1s}}, {{1m}}, {{1h}},
{{1d}}, {{1w}}, {{1M}}, {{1q}}, {{1y}}) and the names {{Second}} to {{Year}}.
Any other value, such as {{2d}}, {{day}} or {{30m}}, fails when the engine
request is built. The error is only logged and the caller gets an empty HTTP
204, the same symptom as UNOMI-1014. This happens on both Elasticsearch and
OpenSearch.
h3. Ways to explore
* Validate the interval in {{DateAggregate}}, or where {{QueryServiceImpl}}
builds it, and reject unsupported values with a clear HTTP 400 that lists the
accepted ones.
* Document the accepted values.
h3. How to test
{{POST /cxs/query/profile/properties.lastVisit}} with a date aggregate whose
interval is {{2d}} returns a 400 naming the accepted intervals, on both
engines. {{1d}} and {{Day}} still work.
was:
h3. Summary
A date aggregate accepts the short interval forms ({{1s}}, {{1m}}, {{1h}},
{{1d}}, {{1w}}, {{1M}}, {{1q}}, {{1y}}) and the names {{Second}} to {{Year}}.
Any other value, such as {{2d}}, {{day}} or {{30m}}, fails when the engine
request is built. The error is only logged and the caller gets an empty HTTP
204, the same symptom as UNOMI-1014. This happens on both Elasticsearch and
OpenSearch.
h3. Ways to explore
* Validate the interval in {{DateAggregate}}, or where {{QueryServiceImpl}}
builds it, and reject unsupported values with a clear HTTP 400 that lists the
accepted ones.
* Document the accepted values.
h3. How to test
{{POST /cxs/query/profile/properties.lastVisit}} with a date aggregate whose
interval is {{2d}} returns a 400 naming the accepted intervals, on both
engines. {{1d}} and {{Day}} still work.
> Aggregate with an unsupported date interval returns an empty response instead
> of an error
> -----------------------------------------------------------------------------------------
>
> Key: UNOMI-1021
> URL: https://issues.apache.org/jira/browse/UNOMI-1021
> Project: Apache Unomi
> Issue Type: Bug
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0
>
>
> h3. In short
> When a report is requested by an unsupported time period, for example "every
> 2 days", Unomi returns an empty answer instead of saying the request is
> wrong. The person or application asking cannot tell what went wrong, and the
> problem only shows up in the server logs.
> h3. Summary
> A date aggregate accepts the short interval forms ({{1s}}, {{1m}}, {{1h}},
> {{1d}}, {{1w}}, {{1M}}, {{1q}}, {{1y}}) and the names {{Second}} to {{Year}}.
> Any other value, such as {{2d}}, {{day}} or {{30m}}, fails when the engine
> request is built. The error is only logged and the caller gets an empty HTTP
> 204, the same symptom as UNOMI-1014. This happens on both Elasticsearch and
> OpenSearch.
> h3. Ways to explore
> * Validate the interval in {{DateAggregate}}, or where {{QueryServiceImpl}}
> builds it, and reject unsupported values with a clear HTTP 400 that lists the
> accepted ones.
> * Document the accepted values.
> h3. How to test
> {{POST /cxs/query/profile/properties.lastVisit}} with a date aggregate whose
> interval is {{2d}} returns a 400 naming the accepted intervals, on both
> engines. {{1d}} and {{Day}} still work.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
