Following this read to retrieve event logs from my contract:
https://goethereumbook.org/event-read
When I loop over the logs like below, I'm getting empty vlog.Data that triggers the error:
abi: attempting to unmarshall an empty string while arguments are expected
for _, vlog := range logs
However, len(logs) shows that there are events, and I can still get some info such as vlog.Topics. Is there any way to fix this or an alternative solution to retrieve event logs?
Turns out the first iteration of looping over the logs is empty for some reason, I was able to solve it just by continuing on to the next iteration.
Related
We use a fork of Quorum, and I'm trying to use Go code generated by abigen to call our contracts. I can dial and get the client, but every call so far has died with:
"abi: attempting to unmarshall an empty string while arguments are expected"
This comes from abi.go when it tries to Unpack the results in argument.go when contract.Call is called.
I read one speculation that this message is caused by incompatible genesis blocks?
Any help greatly appreciated.
abigen generated code works just fine on Go Quorum - nothing to do with genesis blocks. If your server IP that you are dailing and the contract IDs are not in sync, you'll get an empty result (with no error message).
My scenarios is: I have created an object and I have to pull the logs for that object. Log contains 10 IDs each have status like running or finished etc.
I want to check status for each ID, if it is finished then need to run next sampler; if failed then, exit the loop.
I tried while controller with condition ${__javaScript("${IDstatus}" !="FINISHED")}. Loop never exit, even status is finished.
Your JSON response contains finished string, and your are comparing it with FINISHED. Strings in JavaScript are case sensitive so x != X
So my expectation is that if you change your While Controller condition to
${__javaScript("${IDstatus}" !="finished")}
your While Controller will start working as expected.
References:
JavaScript Comparison and Logical Operators
JavaScript Variables
Using the While Controller in JMeter
I have an application that attaches to a docker container to get its output using the containerAttach() function provided by the docker library.
That function returns a HijackedResponse struct with a pointer to a bufio.Reader.
I'm trying to stream text from the bufio.Reader to stdout and getting unexpected characters in the strings written to stdout.
The code:
_, err := io.Copy(os.Stdout, hijackedResponse.Reader)
Expected output:
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.
Actual output:
6Refreshing Terraform state in-memory prior to plan...
=The refreshed state will be used to calculate this plan, but
9will not be persisted to local or remote state storage.
I have no idea where the first character in each of those lines has come from. Any help would be much appreciated. If needed I can provide more details around the docker container & attach options I'm using in my code although I'm assuming they're fine as I'm getting the output via the reader.
I found the problem - my containerConfig needed to specify Tty: true
How can i clear previous error log in Testcomplete
as the object is visible after some time. I am using Do until loop to wait and get the object, the error is logged when the object is not visible.
But the object is visible after some time loop is ran. Can i clear the previous error logs, or do i have any other solution for it. Please help...
Thanks
You might want to use the objects Exists property as it does not throw error messages (afaik). A quick draft (untested):
while not Aliases.Device.Mapped.Name.Of.Object.Exists
' Wait
wend
I'm trying to use the Go pubsub library against the local emulated pubsub server. I'm finding that the "old style" (deprecated) functions (e.g. CreateSub and PullWait) work find, but the "new style" API (e.g. Iterators and SubscriptionHandles) does not work as expected.
I've written two different unit tests that both test the same sequence of actions, one using the "new style" API and one using the "old style" API.
The sequence is:
create a subscription
fail to pull any messages (since none available)
publish a message
pull that message, but don't ACK it
lastly pull it again which should take 10s since the message ACK timeout has to expire first
https://gist.github.com/ianrose14/db6ecd9ccb6c84c8b36bf49d93b11bfb
The test using the old-style API works just as I would expect:
=== RUN TestPubSubRereadLegacyForDemo
--- PASS: TestPubSubRereadLegacyForDemo (10.32s)
pubsubintg_test.go:217: PullWait returned in 21.64236ms (expected 0)
pubsubintg_test.go:228: PullWait returned in 10.048119558s (expected 10s)
PASS
Whereas the test using the new-style API works unreliably. Sometimes things work as expected:
=== RUN TestPubSubRereadForDemo
--- PASS: TestPubSubRereadForDemo (11.38s)
pubsubintg_test.go:149: iter.Next() returned in 17.686701ms (expected 0)
pubsubintg_test.go:171: iter.Next() returned in 10.059492646s (expected 10s)
PASS
But sometimes I find that iter.Stop() doesn't return promptly as it should (and note how the second iter.Next too way longer than it should):
=== RUN TestPubSubRereadForDemo
--- FAIL: TestPubSubRereadForDemo (23.87s)
pubsubintg_test.go:149: iter.Next() returned in 7.3284ms (expected 0)
pubsubintg_test.go:171: iter.Next() returned in 20.074994835s (expected 10s)
pubsubintg_test.go:183: iter.Stop() took too long (2.475055901s)
FAIL
And other times I find that the first Pull after publishing the message takes too long (it should be near instant):
=== RUN TestPubSubRereadForDemo
--- FAIL: TestPubSubRereadForDemo (6.32s)
pubsubintg_test.go:147: failed to pull message from iterator: context deadline exceeded
FAIL
Any ideas? Are there any working examples using the new-style API? Unfortunately, the Go starter project here uses the old, deprecated API.
(Note: It looks like the line numbers in your example output don't match the code that you've linked.)
But sometimes I find that iter.Stop() doesn't return promptly as it should
A few changes have landed recently which fix the excessive delay when calling iter.Stop. It should now return promptly if all messages have been acked. Try syncing and testing it out again.
(and note how the second iter.Next too way longer than it should):
In you code that uses the new API, you first do a pull from an empty subscription, using a context with a 1s deadline. Let's call this "Pull request A". Although the underlying http request is cancelled, it seems that the connection is not being closed in any way that the server respects. So, as far as the server is concerned, "A" is still pending. Immediately after publishing, you make a new pull request, let's call that "B". After a message is returned via pull request B, you leave the message unacked, and make another pull request, "C".
Now, when you publish the message, the server will deliver it to either "A" or "B". If it delivers it to "A" first, you will see the first pull exceeding the 5s context deadline. If it is published to "B" first, you will see the first pull returning quickly, as expected. After the message is published to "B", and left unacked, the server will redeliver it to "A", or "C". If it picks "A" first, then you will end up with the second pull taking longer than expected. If it picks "C", then you will see both first and second pulls taking as long as you expect.
If you don't do that initial pull from the empty subscription, you should see your test behave as you expect.
Note: You don't see any of this when you use the old API because you're not doing the extra "pull from empty subscription" request with the old API (presumably because it doesn't properly support a cancellable context).
Aside: if you want to leave a message unacked, you should call Message.Done(false).