[Azure Monitor Query] Test cases for querying logs

[srnagar]

Logs query

Client test

• Every request should include user-agent header in the expected format
• Test distributed tracing instrumentation
• Test support for different cloud environments*

Single query

• Test a single query - happy case
• Test a single query with partial success (returns 200 response but response body has tables + error)
• Test a single query that returns an error (non-200 response)
• Test all column data types are handled
• Test mapping a table row into a strongly typed model
• Test query for specific time ranges
  • Start and end datetime range (2021-06-08/2021-06-09)
  • Start datetime and end duration (2021-06-09/PT3H)
  • Start duration and end datetime (PT3H/2021-06-09)
  • Duration (PT12H)
  • No time range (query full dataset)
• Test query that returns statistics
• Test query that returns visualization data
• Test query that requires > 3m to run and set server timeout value to 10 m
• Test query that uses additional workspaces
  • Azure resource id
  • Workspace name
  • Workspace id
  • Fully qualified resource id

Batch query

• Test a batch request - happy case
• Test a batch request with error (server returns non-200 response)
• Test a batch request with partial success (some queries in batch fail)
• Test a batch request with individual queries returning partial success (single query in a batch has status 200 with error in the result)
• Test a batch request which contains a query that requires > 3m to run and set the server timeout value to 10 m for that query
• Test a batch request that returns statistics (for some or all queries in the batch)
• Test a batch request that returns visualization data (for some or all queries in the batch)
• Test a batch request that uses different workspaces for different queries in the batch
• Test a batch request that uses additional workspaces for a query in the batch
• Test a batch request that has n queries (n > 200) in a batch (service supports up to 200 requests in 30-second window) to validate server returning 429 response for n - 200 queries and successful response for first 200 queries.

[pakrym]

Test a single query with partial success (returns 200 response but response body has tables + error)

What's the expected user experience?

[pakrym]

Test query that returns visualization data

How do we plan to expose the visualization data?

Same as statistics.

[srnagar]

What's the expected user experience?

@pakrym The result will contain a non-null tables property and error property when this happens. The user should ideally check for both to ensure there are no errors.

However, most users would check the error field and assume the query failed (if they check errors first) or assume that the query succeeded if the tables field had results even though it was only a partial success. So, we should clearly document and provide samples to check for both fields.

We could additionally include an enum to indicate the result status - {ERROR, SUCCESS, PARTIAL_SUCCESS} to make this obvious and the user can check this first to know how to process the result.

Thoughts?

[pakrym]

Thoughts?

Sounds good on exposing error. I've also exposed a HasFailed property to differentiate between full failure and partial one.