newman randomly runs old assertions - newman

I'm using newman npm package and running it in a NodeJS program by passing collection through postman api.
newman.run({collection:https://api.getpostman.com/collections/unique_id, ...
One of the assertion failed. The problem was in the assertion itself and I updated the assertion in Postman UI. When I run program again, even though I am leveraging Postman APIs to pass the collection, it still throws the same error in random runs. Sometimes it is successful while sometimes it fails. Running https://api.getpostman.com/collections/unique_id in browser always yields the latest version.
This unpredictable behavior can run many false alarms. Is there a way to force newman always to work with latest version? There doesn't seem to be any caching thing unless it sends some header which causes Postman APIs to have caching issues.

Related

Cross site issue with Microsoft Graph Toolkit

I'm following this tutorial to create a simple web app with a Microsoft 365 login. I'm currently getting this error when debugging locally (http://localhost:8080):
Warning:
mgt-loader.js:61 A parser-blocking, cross site (i.e. different eTLD+1) script, https://unpkg.com/#microsoft/mgt/dist/bundle/wc/webcomponents-loader.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
In Azure, I have the Redirect URIs set up to match (http://localhost:8080).
After some googling, I tried adding async, but then I get this warning and the login button doesn't appear:
mgt-loader.js:61 Failed to execute 'write' on 'Document': It isn't possible to write into a document from an asynchronously-loaded external script unless it is explicitly opened.
What would be causing this warning and how can I fix it?
First, check out how document.write works: https://developer.mozilla.org/en-US/docs/Web/API/Document/write
You will understand why you cannot run document.write in asynchronous context (try running document.write('Hello world!'); in console on any page).
Warning tells you that a parser blocking (synchronous), cross site (not coming from the same domain as website) scripts can be blocked by Chrome in the future if someone has unstable or bad internet connection.
If you want it to run synchronously without that warning, you have to bundle that JS code with your own, or just serve it from your own origin, same as your website (e.g. localhost:8080). You can download #microsoft/mgt npm package and for bundling - use gulp, webpack or other tool of your choice.
https://unpkg.com/#microsoft/mgt#2.4.0/dist/bundle/wc/webcomponents-loader.js
This script tries to differentiate between async and sync contexts (line 175) and run document.appendChild (instead of write) for async context - but for some reason the check fails (readyState === loading).
https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState
How to check if an Javascript script has been loaded Asynchronously (Async) or async attribute is present?
If you want to run this in non-blocking manner, you could try to fix the script by yourself.
There is a Github repo for that toolkit (https://www.npmjs.com/package/#microsoft/mgt), but there is no issue regarding async loading, nor regarding the warning that you have noticed - so maybe nobody else has noticed or thought about it yet.

"failed to get context" error against real server, works fine with mockserver

Following the ODATA V4 tutorial in step 2: app runs against mockserver, tips are given to run it against a real server. Used the existing index.html as test/mockServer.html and created a new index.html, pointing to ComponentSupport for oninit. Added cors-anywhere and adjusted the manifest. Works well, both mockserver and real.
That was in step 2 and the app worked fine also against a real server. Fast-forward to step 5 and I notice the app fails to load any data when running against a real server. Long story short, the backend is throwing an error, not even "count" together with "top" is accepted. I checked the docs for ODATA, "count" does not seem to be an exclusive option.
Am I fundamentally misunderstanding the way ODATA works? I am especially puzzled by the fact that the mockserver runs fine.
EDIT: created bugreport
As reported in the closing comment of my bugreport, Microsoft has confirmed the issue: "This was due to an error in the version of the OData WebAPI library we were using in the backing service. I have an update with various fixes, including updating to the latest WebAPI library that contains this fix, that I just haven't pushed out to production yet. Let me see when if I can get that deployed."

Dataflow with Go SDK failing with 'InvalidProtocolBufferException'

We were previously running Beam 2.11.0 which started failing due to an apparent change in URN format. When I attempted to update and use the latest release (2.13.0) the pipeline started timing out, and the only seemingly relevant error that I could identify from the logs during testing was:
org.apache.beam.vendor.grpc.v1p13p1.com.google.protobuf.InvalidProtocolBufferException: While parsing a protocol message, the input ended unexpectedly in the middle of a field. This could mean either that the input has been truncated or that an embedded message misreported its own length.
To further test this, I attempted to use the wordcount example as provided in the Beam docs/repo here - https://beam.apache.org/get-started/wordcount-example/ - But I got the same result. I'm not sure if this is a generic error or something to do with Dataflow. The pipelines seem to work when running via direct runner.
Note: I have rebuilt our worker_harness_container_image with the latest version.
I understand the Go SDK is not officially supported by Dataflow, but could anybody tell me if the error is something related to Dataflow or some other issue?
PS: I've asked the question in Dataflow and Beam Slack channels but haven't had any response.

Running Geb + spock tests headless

I have a number of geb functional tests for a grails application.
The tests are working as expected when executed from terminal or IDE.
Although the tests need to be executed by hudson, so they are run in headless mode using Xvfb.
The problem is that the tests keep failing, or behaving unexpectedly, returning errors like RequiredPageContentNotPresent and Stale Element Reference Exception in places that doesn't make sense.
For example:
(at LicencePage is verified above, and page isn't changed)
when:
addDocument(Data.Test_Doc_name,Data.Test_Doc_file)
sometimes throws
Failure: Add Actual Licence (HomePageSpec)
| geb.error.RequiredPageContentNotPresent: The required page content 'addDocument - SimplePageContent (owner: LicencePage, args: [Functional Test Doc, /var/lib/hudson/jobs/KB-Functional_Tests/workspace/app/../manual_test_data/so_v3/os_test_1], value: null)' is not present
at geb.content.TemplateDerivedPageContent.require(TemplateDerivedPageContent.groovy:61)
at geb.content.PageContentTemplate.create_closure1(PageContentTemplate.groovy:63)
at geb.content.PageContentTemplate.create(PageContentTemplate.groovy:82)
at geb.content.PageContentTemplate.get(PageContentTemplate.groovy:54)
at geb.content.NavigableSupport.getContent(NavigableSupport.groovy:45)
at geb.content.NavigableSupport.methodMissing(NavigableSupport.groovy:121)
at geb.Browser.methodMissing(Browser.groovy:194)
at geb.spock.GebSpec.methodMissing(GebSpec.groovy:51)
at HomePageSpec.Add Actual Licence (HomePageSpec.groovy:228)
The method addDocument() is defined on an 'abstract' page, which LicencePage is extending. In most cases like this, if I copy the method code directly into my Spec, it is going to work, although its ruining all the structure I have on my test pages.
Anyone has experience running geb tests with Xvfb? Have you faced these issues?
All tests are passing when executed locally, and this not a data issue as the DB is always cleared
Also, without making any changes, the tests are behaving non-deterministic (on hudson) so the above exception is not always thrown. Without any changes at all, tests are sometimes successful and sometimes fail.
The description you gave seems to be the symptom of a flackey test-suite. we were facing this problem as well some time ago. A good starting point for this is this presentation (around min. 35) and the documentation about the wait stuff in geb.
If you think, it could have something to do with xvfb (where i have no experiences with), you could try to use phantomjs as the test-runner and check if it works correctly.

JBoss not responding to valid URLs

I encountered strange behavior of an JBoss AS 7 on linux server. When I deploy war with my application, the server doesn't respond for valid HTTP requests for this app. When I try to GET a valid URL, I can see in logs, that backend functions (e.g. DAO methods) are called, debug logs shows that subsequent tags in my JSF are rendered, I even can see a message Rendering View index.xml, but the response never reaches the client.
When I use a non-existent URL (e.g. index.asd) response is 404 and when I use a wrong page name (e.g. inswxasd.xhtml) the response is 500. Thus it fails only with valid requests.
I tried to connect both remotely (using firefox) and locally (with wget) and I reproduced the problem. The strange thing is that I deploy the war that I already used and then it worked.
EDIT 1:
I've just noticed that when I send a request to, the server process takes 200% of CPU. Additionally it happens for only one application with stack: Hibernate, Spring, JSF 2.0, Primefaces.
EDIT 2:
Here is pastie with jstack output (jstack -l -F <PID>). All threads are blocked.
Additionally I noticed (using top and dumping stack of the JBoss process) that the problem is most probably caused by a thread called http--0.0.0.0-8080-1. Any ideas?
Thanks for help. I reverted the database to previous state, and it started to work. Apparently there was a problem in the data that caused this infinite loop. Now we need to find it, but as it is reproducible, I'll manage.

Resources