Query Parameter of Log HTTP request not returning 'rawBody' response in Zerocode

[byrnej14]

Hi all,

Hoping someone may have come across this behaviour. We are trying to get recent entries of the log of a Pod in a namespace.

I am referring to this API: https://docs.okd.io/3.9/rest_api/api/v1.Pod.html#Get-api-v1-namespaces-namespace-pods-name-log

We have verified that an entire log file is returned using Zerocode when no query parameters are specified. We have also verified the query parameters work when using another tool such as Insomnia/Postman.

We currently have an issue with the query parameters for the log file HTTP request. The request is the following:

- name: get_logs
    url: "${cluster.api.endpoint}{Endpoint}/log?sinceSeconds=10000"
    method: GET
    request:
      headers:
        Authorization: ""
        Content-Type: application/json
        Version: 2.1.0
        Accept: "*/*"
      body: { }
    verify:
      status: 200

This sinceSeconds query Param returns no logs. We get a valid response with no 'rawBody' returned.

If the query param is removed entirely or if we change the Seconds to lower case 's'. Then we get the entire log in the

response:
"rawBody" : "Generating keystore /var/..... Wed Sep 14 17:10:0......." etc.  which verifies the url should be working.

This problem repeats for any of the options given in the API above. For instance tailLines=10 will return nothing. taillines=10 will return the entire log.

Either way, there are two issues. Our parameter limits are not being adhered to, but also there seems to be an issue with Upper Case letters passed in the query param.

Any thoughts appreciated!

[Anushka2510]

@authorjapps @byrnej14 is this issue still open? I am interested to take this.

[authorjapps]

....We have also verified the query parameters work when using another tool such as Insomnia/Postman.

@byrnej14 , Can you please provide the Request & Response or Screenshots please ?

This will help other to solve by looking at the data and API behaviour etc.

[authorjapps]

@authorjapps @byrnej14 is this issue still open? I am interested to take this.

Yes please. Thank you for your interest in solving this.

Once you get more clarity about the problem, you can pick this ticket and fix it.

Please ask the reporter any question that might help you to get to the buttom of the issue.

[byrnej14]

....We have also verified the query parameters work when using another tool such as Insomnia/Postman.

@byrnej14 , Can you please provide the Request & Response or Screenshots please ?

This will help other to solve by looking at the data and API behaviour etc.

Hi @authorjapps @Anushka2510,

I have tested this issue again this morning and I see the issue is still there but in a slightly different fashion.

Using the sinceSeconds query param, I ran this URL through both Insomnia and Zerocode:
https:/{Endpoint}/api/v1/namespaces/lifecycle-manager/pods/cp4na-o-daytona-64656697d7-8fzvd/log?sinceSeconds=50000

The Insomnia Response is correct:
InsomniaLog.txt

The Zerocode response for sinceSeconds query parameter now returns to first Log message only. In the original bug I created last year it was not returning anything.
zerocodeLog.txt

I then tested tailLines=20 and noted the exact same behaviour in zerocode. It only returns the first item in the list. Insomnia returns all 20 as expected.

Zerocode response body tailLines=20
zerocodeLog1.txt

[authorjapps]

@byrnej14 , Thanks for the reply.
Can you try sending query-params in the request, like below?
Then see if it responds with anything as expected.

"request": {
       ...
       "queryParams": {
            "sinceSeconds": 50000
        }
}

Also, please attached the log in text format as you did earlier if you see any difference.
That might help in understanding the issue.

[byrnej14]

@byrnej14 , Thanks for the reply. Can you try sending query-params in the request, like below? Then see if it responds with anything as expected.

"request": {
       ...
       "queryParams": {
            "sinceSeconds": 50000
        }
}

Also, please attached the log in text format as you did earlier if you see any difference. That might help in understanding the issue.

Tried this. There was no difference in response. Returned a single Log entry again.

Attaching the scenario.

scenario.txt

[authorjapps]

@Anushka2510 , will you be able to pick this and investigate or try to reproduce?
Then come up with a potential fix if reproduced or any issue found?
Let me know your thought on this.

[mhraza95]

@authorjapps @byrnej14 , is this issue still open? I'm interested in working on this.

[authorjapps]

@authorjapps @byrnej14 , is this issue still open? I'm interested in working on this.

Hello, please proceed and provide your input before the actual fix if possible.

[mhraza95]

@authorjapps @byrnej14 , is this issue still open? I'm interested in working on this.

Hello, please proceed and provide your input before the actual fix if possible.

First of all thanks for giving me opportunity to work on this project. I just went through the project to understand it, I will fork the code and I'll start investigating this issue, after the investigation, I'll share my thoughts with you regarding the solution approach to fix this issue.

[authorjapps]

@authorjapps @byrnej14 , is this issue still open? I'm interested in working on this.

Hello, please proceed and provide your input before the actual fix if possible.

First of all thanks for giving me opportunity to work on this project. I just went through the project to understand it, I will fork the code and I'll start investigating this issue, after the investigation, I'll share my thoughts with you regarding the solution approach to fix this issue.

Sounds great mate.
Go ahead please

[yshashanky]

Hey, @authorjapps , I'd like to help solve this one. Let me know if I can start on this.

[authorjapps]

Hey, @authorjapps , I'd like to help solve this one. Let me know if I can start on this.

Hello, thanks for your interest. Please go ahead and put your analysis into this ticket when ready.

[roulpriya]

@authorjapps @byrnej14 is this issue still open? I am interested in taking this.

[authorjapps]

@authorjapps @byrnej14 is this issue still open? I am interested in taking this.

Yes please, you can start on this. Once you confirm that's you get to the root of the issue and can have a PR to fix it, I will be happy to assign this issue to you.
Cheers

[dhruv-bansal]

....We have also verified the query parameters work when using another tool such as Insomnia/Postman.

@byrnej14 , Can you please provide the Request & Response or Screenshots please ?
This will help other to solve by looking at the data and API behaviour etc.

Hi @authorjapps @Anushka2510,

I have tested this issue again this morning and I see the issue is still there but in a slightly different fashion.

Using the sinceSeconds query param, I ran this URL through both Insomnia and Zerocode: https:/{Endpoint}/api/v1/namespaces/lifecycle-manager/pods/cp4na-o-daytona-64656697d7-8fzvd/log?sinceSeconds=50000

The Insomnia Response is correct: InsomniaLog.txt

The Zerocode response for sinceSeconds query parameter now returns to first Log message only. In the original bug I created last year it was not returning anything. zerocodeLog.txt

I then tested tailLines=20 and noted the exact same behaviour in zerocode. It only returns the first item in the list. Insomnia returns all 20 as expected.

Zerocode response body tailLines=20 zerocodeLog1.txt

@byrnej14 - could you please provide response of zerocode and actual API response when you pass tailLines=20 query param.

Between I tried various way, till now I am not able to reproduce issue.
Simple scenario I created is exposing an API that excepts more that 1 query param and then passing query params with various combinations of case via Zerocode. Every time application and is able to capture the right parameters.

I also tried reproducing more close case to yours where I tried returning text/plain response. It is also working fine for me.
I don't have OKD setup to try reproducing what you are facing.