I try to send rawTransactions to Quorum blockchain, the same method that I used for the Ethereum Ropsten.
The issue was I got transaction status returned as '0x0', which is transaction failed according to the online documents.
I would like to know that is that anyways I can get the details of the failing error message from the Quorum blockchain?
The only different is I changed the gasPrice to '0x0' for the Quorum transactions.
Please advise.
Related
I use AMQ 6 (ActiveMQ) on OpenShift, and I use a queue with re-delivery with exponentialBackoff (set in connection query params).
When I have one consumer and two messages and the first message gets processed by my single consumer and does NOT get an ACK...
Will the broker deliver the 2nd message to the single consumer?
Or will the broker wait for the re-delivery to preserve message order.
This documentation states:
...Typically a consumer handles redelivery so that it can maintain message order while a message appears as inflight on the broker. ...
I don't want to have my consumer wait for re-delivery. It should consume other messages. Can I do this without multiple consumers? If so, how?
Note: In my connection query params I don't have the ActiveMQ exclusive consumer set.
I have read the Connection Configuration URI docs, but jms.nonBlockingRedelivery isn't mentioned there.
Can the resource adapter use it by query param?
If you set jms.nonBlockingRedelivery=true on your client's connection URL then messages will be delivered to your consumer while others are in the process of redelivery. This is false by default.
I couldnt figure out how to get the status of the transactions i.e "Fail with error "001010".
The ability to show error message, or the revert reason. depends on the EVM client (GoEthereum, Erigon, Ganache, Ethereum Tester, etc.) There is no bulletproof "standard".
The clients store only the receipt field status that is 0 or 1 (=success)
The clients do not store the revert reason (I might be wrong on this one and this has changed lately)
To get the actual error message you need to replay the transaction and a certain block height using a special eth_call JSON-RPC.
Here is a Javascript library for doing it and a related blog post about the topic.
I am using websphere application server 9.0.0.6.
I have configured a cics Ressource Adapter and the connection factory for that, to connect my cics.
For that connection I am using the cicseci-9.0.0.2.rar driver.
I can connect my CICS but I get an Abend Code:
com.ibm.connector2.cics.CICSTxnAbendException: CTG9638E Transaction Abend occurred in CICS. Abend Code=: AZI6, error code: AZI6
at com.ibm.connector2.cics.ECIManagedConnection.checkReturnCode(ECIManagedConnection.java:1643)
at com.ibm.connector2.cics.ECIManagedConnection.call(ECIManagedConnection.java:1442)
at com.ibm.connector2.cics.ECIConnection.call(ECIConnection.java:122)
at com.ibm.connector2.cics.ECIInteraction.execute(ECIInteraction.java:264)
at at.grz.jp.cics.Interaction.executeSequence(Interaction.java:179)
Due to the reason, that I use transaction mode ECI_EXTENDED instead of ECI_NO_EXTEND.
So I am trying to find a possibility to configure that parameter. On websphere I can't find a custom property that could be fit.
Is it possible to control this by my application?
Any suggestions for me?
The transactional controls for requests made over the ECI resources adapter are controlled by the TransactionAttribute of the method containing the ECI call.
By default methods are called with a TransactionAttributeType of REQUIRED which means a new transaction will be started if it doesn’t already exist and this causes the ECI request to be sent with ECI_EXTENDED.
If you set the TransactionAttributeType to NEVER then there will be no transaction when the ECI call is made and the request will be sent with ECI_NO_EXTEND.
I am having intermittent connectivity problems with an old legacy api that sometimes causes a
'BackendConnectionFailure at transfer-response' error to be returned from Azure API Management. From my experience retrying the request to the legacy api is usually successful. I have a retry policy similar to the below that is checking for 5xx status codes, however, the retries do not seem to take place.
<retry
condition="#(context.Response.StatusCode == 500)"
count="10"
interval="10"
max-interval="100"
delta="10"
first-fast-retry="false">
<forward-request buffer-request-body="true" />
</retry>
Upon further research Application Insights seems to indicate that the Backend Dependency has a call status = false, but a Result Code = 200.
Is there any way to detect this condition so that a retry takes place, or any other policies that can be used?
In your policy above retry covers only receival of response status code and headers from backend. Response body is not proactively read by APIM and instead transferred directly from backend to client piece by piece. That is what "Transfer response" means. By that time all your policies have already completed.
One way to avoid that is to proactively buffer response from backend at APIM side. Try adding as the first thing in outbound:
<set-body>#(context.Response.Body.As<byte[]>())</set-body>
Suppose an ethereum smart contract has external function "foo" whose logic has state-reverting exception require(1 == 0, 'error: you broke the simulation!');.
If ethereum-client A broadcasts transaction "txA" which is a function call on foo, how can ethereum-client B access the state-reverting message corresponding to "txA"?
edit: by "how can", I mean how can a developer practically enable ethereum-client B to access this data. i.e. Can you please point me in the direction of the correct (lower-level.. not webui) api/rpc call from a particular tool?
Clearly this is possible since block explorers provide such messages for failed transactions. I read through some of the source of etherscan, but their javascript is minimized and not easily readable.
Thanks in advance!
See this: https://ethereum.stackexchange.com/questions/39817/are-failed-transactions-included-in-the-blockchain
Failed transactions often are included in the chain.
What you sometimes see, if you're using e.g. MetaMask, is a popup saying "this transaction will fail" that happens before the transaction is sent to the chain. This is MetaMask trying to be helpful and prevent you wasting gas. But you can force send the transaction anyway, and you'll get a failed/reverted transaction posted on-chain (like this one for this Solidity source).
So to answer the original question, if TxA was posted on-chain, then client B will process it and get the revert message itself. If TxA was not posted on-chain, then there is no record of it.