I have migrated some code from the old Azure Mobile Client to DataSync, and the GetItemsAsync method is returning 0 items, although there are items in the database.
Here is the code snippet
public async Task<IEnumerable<Configuration>> GetItemsAsync() { await InitializeAsync(); return await _table.GetAsyncItems().ToListAsync(); }
If I execute the exact same command through the web portal the correct result is returned.
I am expecting the GetAsyncItems to return a list of items (as it did previous using the Mobile Service Client package).
The call returns a list of 0 items.
If I examine the http traffic, the correct request is sent to Azure and the correct response is returned.
Based on your final comment, you are using the client that uses the v3.0.0 ZUMO-API-VERSION and you are using the v2.0.0 ZUMO-API-VERSION backend. I'm surprised it is working at all.
When thinking about the ZUMO-API-VERSION
2.0.0 client works with either a 2.0.0 or 3.0.0 server.
3.0.0 client ONLY works with a 3.0.0 server.
So you can update the server, then update the clients, but not the other way round.
Related
I have the following setup
/template. Loads a page that shows all the templates owned by the current user.
/template/new. Loads a page that allows the user to create a template and save it.
/api/save-template. Receives the frontend call made from /template/new and handles storing it on the db.
With those routes, a typical use case is the following:
User ends up somehow (irrelevant) on /template/new.
User creates a template and hit "save". A spiner shows up while saving happens.
Template payload is sent via POST HTTP request to /api/save-template.
/api/save-template route handles the saving successfully and responds with a status 200.
The spinner finishes and the user is redirected to /template, where the newly created template should hopefully show up.
The problem here is on point 5, where in some scenarios, the newly created template doesn't show up. Here's what happens on different scenarios. The app could be running either using next dev, next build && next start, or deployed on vercel. The database could either be hosted locally on docker, or on the cloud using supabase.
db \ app
next dev
next build...
vercel
docker
✅
✅
haven't tried
supabase
✅
✅
❌
One thing to keep in mind, which might be related to the reason this is not working, is that the redirection is made on the frontend using router.push('/template').
I'm also checking on the client side what templates are available when reaching point 5. I've confirmed this is not a db delay issue because the templates are found by the client. For those checks I'm using the following code:
useEffect(() => {
const checkSupabase = async () => {
const templatesResponse = await supabase
.from<Template[]>('Template')
.select('*')
const templates = templatesResponse.data
console.log('templates found from useEffect')
console.log(templates)
}
checkSupabase()
}, [])
And the last thing I want to point out is that the logs I get from vercel make me think the getServerSideProps is not called. I'm logging templates found from getServerSideProps to see what's available on that function. I see the log before creating the template (time 21:31:24:00), and then the /api/save-template being hit (time 21:31:47:11), but I don't see the second request to /template after the redirect. The logs –note the order is newest on the top– are:
21:31:47:11 - [POST] /api/save-template
21:31:24:00 - [GET] /template
templates found from getServerSideProps
[]
Questions
How is it that I don't see a second log for [GET] /template or the templates found from getServerSideProps log? Is it not being fired?
If getServerSideProps is not fired, how come this works when the app is running locally?
Is there a consistent solution for this use case? I guess it must be quite common to want to see recently created data.
Thanks!
I'm using the graphql_flutter package and am having an issue with what seems to be caching. The client passes over cached data from one user to another, even when the FetchPolicy is set to noCache.
I’ve outlined below what my graphql client setup looks like and then the custom method I use for sending a query to the server (it fetches the items favorited by the user). I’ve looked through the Policies in the official documentation and believe my setup is correct. The issue (and the steps to reproduce) are the following:
I sign in to my app with a test user account (using Amplify Cognito
for authentication) and add some items to the user's favorites list (with a
mutation request).
I then navigate to a ‘Favorites’ summary page,
where I call the below outlined fetchFavoritesData method to fetch
all the items that were favorited by the user. Works like a charm.
I then log out and create a completely new user account and log in with this new user (i.e. different
access token and all).
Before adding any items to the favorites list for this new user, if I check their ‘Favorites’ summary page, which calls the fetchFavoritesData method and should return null (because this user has yet to add any), the result actually returns the exact items that were favorited by the first user. Odd.
Been playing around with the Policies, tried different fetch policies and so on, but the problem remains. Am I missing something (sorry — totally new to this package) or could this be a bug?
GraphQLClient client = GraphQLClient(
link: link,
cache: GraphQLCache(), // declared cache here because I'm using the client for a few different requests, some where caching is preferred.
);
}
Future<void> fetchFavoritesData() async {
final QueryOptions options = QueryOptions(
document: gql(queryFavoritesData),
// only return result from network
fetchPolicy: FetchPolicy.noCache,
// ignore cache data if any
cacheRereadPolicy: CacheRereadPolicy.ignoreAll,
);
final QueryResult result = await GraphQLConfiguration.client.query(options);
}
26/8/2021 UPDATE:
I've migrated over to Firebase for authentication and the error is no longer occurring. Not sure whether the authentication package was the causation or just a correlation but this is no longer an issue.
I just can't seem to get anywhere with this.
I have a web api running fine, with a wpf application using the api via AutoRest.
The api has been uploaded to Azure (App Services)
I now want to lock down the api, so users log in via Active Directory. Again, all users are currently there.
RestCredentials = new TokenCredentials(tokenAuthResult.AccessToken);
Using the RestCredentials I pass in the credentials as type
ServiceClientCredentials
using (var db = new BuxtedAPI(Model.Helpers.Credentials.RestCredentials))
{
var res = db.GetComboList();
ComboValueList = new ObservableCollection<ComboValue>(res);
return ComboValueList;
}
I can see on the log in Azure that the user successfully logs in.
But the system just dies with
Operation returned an invalid status code 'InternalServerError'
No more feedback at all.
Just to note, I am using swagger also here.
I am assuming that the BuxtedAPI call that passing the credentials should pass through the bearer token for the api call to authorise.
I have set nothing else on on webapi code base, no [AUTHORIZED] or anything.
Any chance anyone can help me along here.
Thanks Scott
If anyone else gets in this situation.
The process required Resource Id to be the web app and the clientid to be the native app id.
Scott
Currently it looks like the lice SDK returns error 500 for all request. Also the interactive SDK Microsoft provides here returns the same error:
http://isdk.dev.live.com/dev/isdk/ISDK.aspx?category=scenarioGroup_core_concepts&index=1
My application work without any changes for over 24 months. Has someone any more details or a workaround?
Update: I tried the following API calls both with the same result:
https://apis.live.net/v5.0/me?access_token=#Token#
https://apis.live.net/v5.0/me/picture?access_token=#Token#
Finally, and after a very long downtime (more than 20 hours) the Live API is up & running again.
Unfortunately, there is not even an official announcement from Microsoft.
Up & Running
Have the same problem and all of my apps worked before for very long time.
I'm using LiveSDK 5.6 and getting successful response for LiveAuthClient.LoginAsync with the following scopes: "wl.signin", "wl.basic", "wl.contacts_photos", "wl.contacts_skydrive",
"wl.skydrive_update"
LoginAsync returns LiveLoginResult object where:
Status = Connected
Session = {Microsoft.Live.LiveConnectSession} with AccessToken
but when app trying to call
Session (LiveConnectClient) object with GetAsync ("/me")
I'm getting the following exception
[Microsoft.Live.LiveConnectException] = {"An error occurred while retrieving the resource. Try again later."}
ErrorCode = "server_internal_error"
The OneDrive service experienced a service outage on the 9th, you can see from this 3rd party site for an idea of the timeline. We did not communicate this issue well to you and other developers that have come to expect excellence from OneDrive.
It is the start of a long weekend and I do not have more answers for you at this time, I'll circle back next week with better details on what to do in the future.
The Live Connect API that the LiveSDK works in conjunction with has been replaced by the OneDrive API, which also has SDKs for most major platforms. You will see major performance improvements and a larger feature set such as a modern sync API available for you with this new API if you transition to it.
We're using Apache ManifoldCF. In Admin UI there's report at Status Reports -> Document Status.
Is it possible to get that content through ManifoldCF's Restful API?
The closest thing I've found is org.apache.manifoldcf.crawler.RunDocumentStatus under Control via Commands but I haven't been able to figure out if that can be used through HTTP API (instead of direct Java code)
No, currently you cant if you are looking to find a status of a single document. but if you want to get the status of queue for a connection you can using
repositoryconnectionquery/< encoded_connection_name >.