I'm trying to implement in-app purchases for a Windows Phone 8 app. The docs for RequestProductPurchaseAsync don't exist specifically for the phone. In the Windows Store docs, there's a funny line:
You should treat a success result as indicating the async process
completed without errors. To ensure that the transaction itself was
successful, check the LicenseInformation element in the returned
receipt.
There's no LicenseInformation element (or attribute) in the receipt. There's Receipt, ProductReceipt, and Signature. Question - did anyone work with in-app purchases before? How is transaction failure/cancellation reported?
Got my hands on a real phone.
Cancellation is reported by an async completion (parameters Info, Status) with Status=AsyncStatus.Error, Info.ErrorCode is COMException with HResult=0x80004005 (E_FAIL).
For at least some of the genuine transaction failures (e. g. product ID not found in the catalog), the reported status and HRESULT are the same. I don't think there's a good way to catch a cancellation with the current API. Reporting AsyncStatus.Canceled would be a good idea, but so far it's not implemented.
Related
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.
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.
I've set up a WebRTC application that works as follows: (Beginning at step 5, I stop using CALLER/CALLEE because either the CALLER or the CALLEE can initiate the stream)
CALLER creates peer connection with only a data channel, creates offer, sets local description, and sends offer to CALLEE.
CALLEE sets remote description, creates answer, sets local description, and sends answer to CALLER.
CALLER sets remote description.
CALLER and CALLEE can successfully communicate over the data channel.
PEERA adds an audio and/or video stream to peer connection.
PEERA's onnegotiationneeded event fires.
PEERA creates offer, sets local description, and sends offer to PEERB.
PEERB receives offer, sets remote description, creates answer, sets local description, and sends answer to PEERA.
If PEERA and PEERB are both using Chrome:
If PEERA is the CALLER, then everything behaves normally, and the stream is received successfully by PEERB.
If PEERA is the CALLEE, then PEERB blows up in step 8 when setting the LOCAL description. The stream is received by PEERB, but displays only as a black box when sent to a <video> element.
The error logged is:
Failed to set local answer sdp: Failed to push down transport description: Failed to set SSL role for the channel.
When both PEERA and PEERB are using FireFox:
PEERA can be either the CALLER or CALLEE, and everything behaves normally, and the stream is received successfully by PEERB.
When the CALLEE is using Firefox and the CALLER is using Chrome:
PEERA can be either the CALLER(Chrome) or CALLEE(Firefox), and everything behaves normally, and the stream is received successfully by PEERB.
When the CALLEE is using Chrome and the CALLER is using Firefox:
If PEERA is the CALLER(FireFox), then everything behaves normally, and the stream is received successfully by PEERB(Chrome).
If PEERA is the CALLEE(Chrome), then PEERB(FireFox) blows up in step 8, when setting the REMOTE description.
The error logged is:
DOMException [InvalidSessionDescriptionError: "ICE restart is unsupported at this time (new remote description changes either the ice-ufrag or ice-pwd)ice-ufrag (old): a59T34ixyZjsTUuJice-ufrag (new): rsCN1ugVKHJQzmMbice-pwd (old): KqOHtqdzFp6VwG+3hxbjcQFcice-pwd (new): uVvowvgsKIwuCq/bDmcGbSPA" code: 0 nsresult: 0x0]
Chrome<->Chrome renegotiation
The error you get when PEERA is the callee in the renegotiation is typically due to Chrome changing the DTLS role, however I am not able to reproduce your problem. I believe that this JSFiddle link illustrates the scenario you are describing, and I am able to successfully renegotiate the call using Chrome 47.
If you can still reproduce the problem, take a look at the a=setup: bits of the SDP that are generated in the offer/answer, and compare them to the initial offer/answer. If I'm right, you'll see that to begin with, CALLER will have a=setup:actpass in the offer, and CALLEE will have a=setup:active in the answer. This means that the CALLER is now playing the 'passive' DTLS role and the CALLEE is playing the 'active' DTLS role.
Then when you initiate a renegotiation, PEERA is more than likely sending a=setup:actpass. PEERB, which should send a=setup:passive, is sending a=setup:active instead, which essentially causes a DTLS role swap. The error is due to the fact that Chrome does not support DTLS role changing for peer connections.
There is an open ticket on the google chrome bug tracker related to this, where I have posted a reproduction of the issue you're describing using a different scenario: starting a video-only call and the callee renegotiating to add video+audio.
The only solution that I know of at this time is to "munge" (alter) the SDP prior to calling setLocalDescription, so that it has the values that you want. So, for example, if you are about to process an answer and you know you are the passive DTLS role, you can do like
answer.sdp = answer.sdp.replace('a=setup:active','a=setup:passive');
pc.setLocalDescription(answer).then(...);
Firefox<->Firefox renegotiation
Yep, everything works great! That's because Firefox "does the right thing" with the DTLS roles when renegotiating in all the tests I've run. Take a look at the difference between these SDPs and the Chrome SDPs.
Firefox<->Chrome renegotiation interop
I am able to reproduce the issue you are describing with InvalidSessionDescriptionError showing up in Firefox. I haven't been able to come up with a solution yet nor know the cause at this time.
I'm also having a myriad of other renegotiation interop issues. It's pretty discouraging at the moment.
Please post back if you learn more. Definitely still lots of struggling with renegotiation interop!
I am planning to add in the message carbon function(when a user is logged into multiple device and send a message or/receive a message, it will sync between all devices) for a chat server, i am running on Ejabberd and using strophe.js...
I am wondering if there are plugin written for Ejabberd that i can install and also for strophe.js???
I looked over https://github.com/processone/ejabberd-contrib and the github for strophe.js
None of them seem to have plugins for message carbon. Wondering if anyone has this implemented before??
I have read that if it doesnt, i should treat it as a groupchat??? I am not sure why that would work??? And not exactly sure if thats good for the resources, and what if it scales up, would that have impact on the overall structure.
If it is treated as a group chat, then i assume each resource/session would be treated as a different user? Then when a message is sent into that group, all of those other session/users are updated, so even there are 2 users??
ejabberd supports message carbons as default in latest version.
This feature is unrelated to groupchat and cannot and should not be treated similarly.
If you read XEP-0280 Message Carbons you should see that sending a packet similar to the following is enough to enable it:
<iq id='enable1' type='set'>
<enable xmlns='urn:xmpp:carbons:2'/>
</iq>
You may find also valuable information in XMPP Academy video #2 at 27m30s.
We're building an application that makes extensive use of IndexedDB on Firefox to store offline data.
This works well most of the time but occasionally fails with errors like the following:
Exception... "The operation failed because the requested database object could
not be found. For example, an object store did not exist but was being opened."
code: "3" nsresult: "0x80660003 (NS_ERROR_DOM_INDEXEDDB_NOT_FOUND_ERR)"
It seems to fail in various places in the code; here is one of the culprits:
_writePage: (storeName, startIndex, endIndex, binder) ->
writeTransaction = #connection.transaction([storeName], #idbTransaction.READ_WRITE)
store = writeTransaction.objectStore(storeName)
for index in [startIndex...endIndex] when (item = binder.list[index])?
writeRequest = store.put(item)
writeRequest.onerror = binder.failCallback()
writeRequest.onsuccess = binder.successCallback()
if endIndex >= binder.list.length
binder.finishedRegisteringCallbacks()
return
setTimeout((=> #_writePage(storeName, endIndex, endIndex + #WRITE_EACH_PAGE_SIZE, binder)), #WRITE_EACH_PAGE_DELAY)
null
The thing that puzzles me is that the failures occur infrequently, during automated tests that usually work (we're seeing one of these failures per hundreds of executions).
It's worth mentioning that we're storing a lot of data too, in the order of hundreds of megabytes. Turns out the automated tests only store a few megabytes, so it's not a matter of size.
Has anyone else experienced (or better yet, experienced and fixed!) this problem?
This seems to be a Firefox bug. I've raised Bug 751802 - Intermittent IndexedDB write failures and my colleagues and I are busy working with the Firefox folks to help reproduce it.
For the time being there's no workaround or fix.
Check to see if you have multiple tabs open when this happens. If one of those is in a setVersion (old API) or onupgradedneeded (new API) it's probably going to cause problems in the other.
To debug, be sure you're looking for onblocked (vs. onerror) events when opening the DB.
Adding to #Duncan's answer:
On that thread is an idea to throw a catch in db creation/open
https://bugzilla.mozilla.org/show_bug.cgi?id=751802#ch-8