I am trying to get the transactions of an address using
https://api.etherscan.io/api?module=account&action=txlist&address=0x9bb1499d06f3036a12f653f00b889731d04c47a0&startblock=0&endblock=92649034&sort=asc&apikey=XXXXX
however, I get the results "No transactions found" when in fact, a transaction exists, and can be viewed on etherscan.io site.
I wonder if anyone has encountered the same problem. Is this a bug on the etherscan side? Perhaps the api.etherscan side doesnt not have the most recent transaction information?
Any insights would be greatly appreciated!
Thanks!!
The txlist endpoint only returns transactions from and to to the specified address.
You're trying to view transactions from and to address 0x9bb1.... But this specific tx (on the screenshot) originated from 0x2204... and was sent to contract 0x30ad....
The 0x9bb1... only acts in the event logs produced by the transactions, and most likely the tx was executing a transfer() function with this address as a param.
TLDR: When you're transfering tokens, you're sending a transaction to the token contract - not to the token recepient.
Related
We created a wallet pass and sent the wallet pass invitation email to end-users. However, there was an issue with the back-end APIs which prevented the Apple pass from automatically calling the device registration API.
The question I have is, do we need to re-inform all user to reinstall the Pass, or will the Pass automatically try re-registering by calling the device API.
Thank you.
The way you have worded your question possibly describes an impossible situation. A valid pass will always attempt to register. You state that your API was the issue, but an issue with a web service implementation would not prevent devices attempting to call it.
If the pass.json contains a valid https webServiceURL an authenticationToken, it will call the device registration endpoint after it has been added to the user's wallet. If the device does not get a 201 or 200 response, it will continue to retry, progressively backing off from every few seconds, to every few days for a period of around 2 weeks.
Therefore, if your pass.json contained the correct information; assuming that the issue was with your device registration endpoint and assuming that you picked up and addressed the issue quickly, then you should see device registrations coming in without having to do anything.
If it took longer than a couple of weeks or if you want to accelerate the process, you could ask your users to toggle the Automatic Notifications setting on the back of the pass. This will force the device to attempt a re-registration.
If however, the pass does not contain a webServiceURL, or if the webServiceURL was incorrect, then the device will not call back, or will call the incorrect endpoint. In this case, the only option is to have your users reinstall the pass. In this case, it is not your API that is causing the problem, but your passes.
We have desktop and mobile app (2 different client id) integrated with bim360 api. We have a problem with 429 error responses. Documentation: https://forge.autodesk.com/en/docs/data/v2/developers_guide/rate-limiting/ doesn't give us a lot of details.
How does it work? How can we avoid it?
What will happen if 1000 different users from apps with the same client_id at once try to get issues list? Will it be distinguish as Ddos? Are hubId, projectId, user account, ip address considered in rate-limiting algorithm?
As I know, each API has a well-configured rate-limit per minute per client id. After reaching the limit, you will see a retry-After parameter appears in the response header of each of your API call. It stands for the retry time when you can call the API again, and the unit of this value is in second. You can schedule a retry task along this retry time in your code.
Note. The value of the retry-After will reset if you make another call before reaching the Retry-After duration.
Hope it help, Cheers!
I've cobbled together some code to send some tokens using web3.js 1.0.0-beta46 and then decided to try to send more token than I had in my wallet. to my great surprise the transaction send succeeded and I got a txid, but of course the transfer failed
here's the attempt (on Ropsten):
https://ropsten.etherscan.io/tx/0xaf2708dcc9b86b7cca0076e329a1e81fc28fdc4a97765b0a79544ec0685cfa69
now my question: how can I tell when the transfer succeeded? or for that matter how can I get the error message? etherscan merely indicates:
ERC-20 Token Transfer Error (Unable to locate Corresponding Transfer Event Logs), Check with Sender
The most simple and straightforward way would be to check the balances of sender and receiver before and after the transfer.
Now about the failed transfer, after reading the contract I noticed that in the event of insufficient funds you simple return false, which makes a valid transaction. What you should do is revert the transactions using require to make the checks. That way an invalid transaction will be reverted by the EVM which will be recognized by etherscan and show that the transaction failed.
I'm synchronizing Office 365 mail folders via the Office 365 REST API by doing a GET on me/MailFolders/{folder_id}/messages. For two different accounts, I've recently been getting 500 responses to these GETs with the error code ErrorMessagePerFolderCountReceiveQuotaExceeded and error message "The number of received messages has exeeded the quota for the folder." (Typo theirs, not mine.)
I can't find any documentation on this error. What does it mean? What should I do to fix this situation?
I couldn't seem to find any documentation for it either.
From the error message, it seems it might be related to the "Maximum number of messages per mailbox folder" limit on Exchange Online. Do you know if the folder contains 1M+ messages?
https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx#MailboxFolderLimits
I guess my other idea would be that you're getting too many messages in too short of a time period. Suggestion would be to use the endpoint GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages with $deltaToken and $skipToken to skip previously synced messages.
https://msdn.microsoft.com/en-us/office/office365/api/mail-rest-operations#synchronize-messages
When you do a sync to an Exchange folder via the Outlook REST API, you pass it a sync token. In response, the API returns a new sync token and a set of changes. And the client is expected to send the new token back with their next sync request.
With most systems that support sync, using a stale sync token (i.e. one that has been sent to the server once) in a subsequent request will generally just succeed with no problems. And Exchange appears to work like that... for the first 999,999 times you do it. On the 1,000,000th time (and each time thereafter), you get ErrorMessagePerFolderCountReceiveQuotaExceeded. This is (I think) because Exchange keeps track of each token that it's given out and updates the token in its store each time it's used for sync. If a client uses a stale token, Exchange views it as a new client and adds that stale token as a new entry in its list of active tokens. That active token list can have at most 1,000,000 entries. ErrorMessagePerFolderCountReceiveQuotaExceeded is the cryptic error indicating that Exchange's active token list has overflowed.
When sending a notifications to a notificationhub I receive the following exception:
Microsoft.ServiceBus.Messaging.QuotaExceededException: The remote
server returned an error <403> Forbidden. The maximum number of
Notification operations has been reached or exceeeded. Actual:33360,
Max allowed: 33000..TrackingID55ccd1f7a791-4047-96fd-0d0be2278ff7_g7
Any ideas on how to fix this problem?
What you should keep in mind is that it appears that all operations (not only sending notifications) you do with the NotificationHubClient seems to add to your daily Operations Quota.
I have made the mistake of doing unnecessary registration updates whenever the client logs on to my API.
Device registrations are valid for 90 days, so I'll not have to make any updates unless the registration has/about to expire. (I do save the expire date, which you'll get from the RegistrationDescripton.ExpirationTime, in my user table in my server app for knowing when to do a registration update)