I am doing the following request on a repo in my github pages (https://github.com/equalcoding/equalcoding.github.io - /js/main.js)
let ele = document.getElementById('blog');
let request = new XMLHttpRequest()
request.open('GET', `https://dev.to/api/articles?username=${devtoUsername}&state=${state}&per_page=${perPage}&page=${page}&time=${new Date()}`, true)
request.onload = function () {
response = JSON.parse(request.response);
response.forEach(response => populateBlogDOM(response, ele));
}
request.send();
Yesterday I created a record in the API provider and it gave me a single result which was correct, however, today I created another record and it still returns the same record it did yesterday. However, when I test this locally it works fine and I get both records.
Below is side by side comparison of the two requests. Same parameters just the environment is different. This makes me wonder if it is something GitHub does. If so how do I disable this?
Related
I try to get return report from amazon, but my request is always cancelled. I have working request report using
'ReportType' => 'GET_MERCHANT_LISTINGS_DATA',
'ReportOptions' => 'ShowSalesChannel=true'
I modify it by changing ReportType and removing ReportOptions. MWS accept request by its always cancelled. I also try to find any working example of it on google but also without success. Meybe somone have working example of it? I can downolad report when I send request from amazon webpage. I suppose it require ReportOptions, but I dont know what to put in this place (I have only info ReportProcessingStatus CANCELLED). Normally I choose Day,Week,Month. I check on amazon docs but there isnt many informations https://docs.developer.amazonservices.com/en_US/reports/Reports_RequestReport.html
Any ideas?
Note: This is not new, but I have some new insights on it.
For about three weeks now I regularly try to deploy the development-schema of my CloudKit Container to production, using the CloudKit Dashboard:
It spins for exactly a minute to then tell me "There was a problem loading the environment's status"
This is not new, many other questions face this as well:
Error CloudKit Dashboard - There was a problem loading the environment's status
Does iCloud need to be in the Production environment in order to use in Production?
iCloud dashboard: Cannot deploy CloudKit schema to Production
Apple support told me to
look at https://developer.apple.com/forums/thread/656723 (try again after a day with stable network)
use Safari and resetting browser settings to clear cache and cookies
"You may also try creating a new CloudKit container, rebuilding your schema, and then try again." => obviously doesn't work, because users have data on production
TL;DR:
Kill the timeout by running this in the console:
var id = window.setTimeout(function() {}, 0);
while (id--) {
window.clearTimeout(id); // will do nothing if no timeout with id is present
}
(the response is undefined — that's okay)
How I got there
So I started to look at the requests the site makes to the backend when I click "deploy". Chrome shows that the request to
https://p39-ckdatabasews.icloud.apple.com/r/v3/user/<container-name>/production/public/admin/deployment/status?team_id=<team-id>
is cancelled after 1.0 min.
Insight 1
The problem is with the production schema. I had used the Reset Development Environment before to make sure I hadn't messed that up myself, but this would have spared me that.
I used the Copy as cURL command (in Chrome, because it also copies the auth cookies, which Safari does not) and ran it in Terminal.
Interestingly, that does respond after 1'37 min. That's also what the X-Apple-Edge-Response-Time: 97244 header says.
If you know what to look for, the console will also tell you the the request timed out:
Insight 2
The server takes too long to respond (> 1min) and the client script times out (at 1 min)
Note: You can also get a response by right-clicking the request in Chrome and choosing "Replay XHR".
Solution
I tried to understand the JavaScript that sends the XHR request and modify the timeout, but I failed. However, you can apparently clear all timeouts that exist with
var id = window.setTimeout(function() {}, 0);
while (id--) {
window.clearTimeout(id); // will do nothing if no timeout with id is present
}
(from https://stackoverflow.com/a/8860203)
Running that while waiting for the response actually worked for me!
I have a typical REST-ful API doing CRUD operations on a DynamoDB being served by a Python web server written with Flash and Boto3. My get_list function looks like this:
def list_items():
table = dbh.Table(table_name)
response = table.scan(ConsistentRead=True)
return { "items": response["Items"] }
And also an update which looks like this:
def update_item (item_id):
table = dbh.Table(table_name)
input_json = request.get_json()
table.put_item(Item = {
"uuid": str(item_id),
"data":input_json
})
return {}
My web app is calling the API endpoint for update_item, waiting for completion, and then immediately calling the API endpoint for list_items when it gets a return value from update_item. list_items is using ConsistentRead, which I was expecting would wait until the previous writes are done. But the list of items is consistently missing the new updates. A call to list items moments later gives the full update. How can I ensure that if I call these API endpoints back to back I get the most up-to-date results. Or if I can't, how should I structure my web app so that when I edit an item, I can see the updates without sleeping an arbitrary amount of time after an update?
According to the docs
If ConsistentRead is true, then all of the write operations that
completed before the Scan began are guaranteed to be contained in the
Scan response.
I'm not familiar with Boto / Python, but is the Put being done async?
If it's not completed when the scan starts, you'd see the behavior you describe.
We have an app that uses AWS Cognito for authentication. The backend code (using AWS SDK for C# works fine mostly)
After the initial login, we obtain, ID, Access and Refresh TOKEN. Then every hour we try getting a new ID and ACCESS token by calling
public bool ExtendTokens(string userRefreshToken, out AdminInitiateAuthResponse output)
{
output = null;
AdminInitiateAuthRequest request = new AdminInitiateAuthRequest();
AdminInitiateAuthResponse response = new AdminInitiateAuthResponse();
try
{
request.UserPoolId = XXXXXXXXXXX;
request.ClientId = YYYYYYYYYY;
request.AuthFlow = AuthFlowType.REFRESH_TOKEN_AUTH;
request.AuthParameters.Add("REFRESH_TOKEN", userRefreshToken);
response = awsCognito_client.AdminInitiateAuth(request);
if (response != null)
{
output = response;
return true;
}
}
catch (Exception ex)
{
//log the exception and the inner exception!
}
return false;
}
on the backend side and passing them to the client. (The way this app works is that the client makes few calls every 3min to the server, and then server calls Cognito for authentication) then after 60min, renewing tokens the first time (60min after initial login) works fine! However, (after precisely 2hrs) the second time I get this error:
The remote server returned an error: (400) Bad Request.
Refresh Token has been revoked
For several internal/external users this happens right on the dot! 120min after they login using Username/Password. So it cannot be where a user signs out or we call GlobalSignOut accidentally. I have checked my code several places, I don't see where I might have goofed! I even use the same code module in another product and that one does not get kicked out at all! (That one does not make calls every now and then!)
Also, Tracking user devices is OFF. So it cannot be this answer.
Moreover, the Cognito Limitation document does not say anything about the total number of calls per account!
Other useful details: the default expiry of our refresh token is 15days. That's why I call this two hours expiry prematurely!
I am not able to reproduce this on my localhost, but it happens after deploying to IIS. I have checked the settings and the web.configs and I could not find any meaningful difference between the two that would invalidate my refresh tokens!
So, I was able to get around this (I still don't know the root cause) but the way to avoid this is to call the renew function every 45~50 minutes instead of waiting for that 1hr to pass! Doesn't make any sense but Its been 48hrs that my session is active and tokens are being renewed.
We are using Apollo GraphQL with subscriptions (via websockets) in a node.js backend and a react frontend.
The app provides a list of devices. When a user clicks on one device he gets the monitoring data for the device with live updates (from the subscription). When the user clicks on another device the subscription is stoppen, the data for the next device is being loaded and subscribed.
I pasted the messages from the websocket connection below. I first tried to paste the raw log here, but the screenshot is much easier to read.
Please ignore the ids 1-5. Important for my problem is id 6 and 7. The id is created when clicking on the first device (at 11:15:35) and then the details are closed so the subscription is stopped (at 11:15:36). Now the user clicks another device and starts subscription 7. Some seconds later the system pushes data for both, the 6th and 7th subscription.
Is there something I can do so "stop" actually means "stop" or is this a bug?
Edit: as requested, here is the code I use to subscribe/unsubscribe (I had to cut some parts due to company regulations)
const subscription = useRef(null)
const { loading, data, error, subscribeToMore } = useQuery(getDevice, { variables: { deviceId } })
useEffect(() => {
return () => {
if (!subscription.current) return
subscription.current()
subscription.current = null
}
}, [deviceId])
if (!subscription.current) {
subscription.current = subscribeToMore({
document: geDeviceSubscription,
variables: {
deviceId
},
updateQuery: (prev, { subscriptionData }) => ({ device: subscriptionData.data.subscribeDevice })
})
}
Edit 2: It is for sure not my clients issue as it also happens if the use the GraphiQL gui, start a subscription and stop it again. The new data is not displayed but it is visible in the websocket connection in the network tab of the browser (chrome).
It seems to have been a bug in an older apollo graphql or nestjs-apollo-graphql version (We use those frameworks in the backend). After upgrading all the backend dependencies to "latest", the bug doesn't seem to persist.