Good day!
In CloudKit Dashboard I get the error:
There was a problem loading the environment’s status
This happens when I select the action "Deploy Schema to Production..." for the "Development" schema:
I have a released application using CloudKit (respectively, there are two working schemes - Development and Production). Before the release of the application, the Development schema in CloudKit Dashboard was translated into Production (Deploy schema to production).
Now I needed to make changes to the schema.
A new field and indexes for it, as well as indexes for an existing field, have been added to the Development schema.
Now I am trying to move the schema from Development to Production in CloudKit Dashboard (so that my changes show up in Production) and
this error persists, is there any other way you can update the Production schema or fix this error?
There can be a lot of strange errors in the CloudKit dashboard. Here are a few suggestions:
Try again later (and always do a hard refresh when you do). Sometimes the error is temporary.
Try in a different web browser. Support for Chrome has improved lately, but there were times when Safari was the only way to make certain things happen.
Create a new CloudKit container, rebuild your schema, and then try to deploy. I've had certain bugs never go away within a particular container and I've had to start over fresh.
If the issue persists, submit a Feedback to the CloudKit team. They have fixed things within a day or two for me in the past.
Aside from that, your particular error isn't terribly descriptive and it's most likely something on Apple's end.
I found out that it runs into a client-side timeout of 1 minute, but the server takes longer. You can kill the timeout with
var id = window.setTimeout(function() {}, 0);
while (id--) {
window.clearTimeout(id); // will do nothing if no timeout with id is present
}
For details, see https://stackoverflow.com/a/67862078/
Related
I recently had an issue with one of my production apps that use Core Data and CloudKit where data wasn't syncing between devices, after a little bit of research I found out that the schema in the private CloudKit container needed to be initialized; which I never did.
The part I'm still not 100% sure is when to run the initializeCloudKitSchema method after the app has been released to the AppStore. I see that Apple recommends running it when testing by using #if DEBUG, but... do you really want to run it every time you compile in Xcode?
Here is how I understand it at this point...
App release, call initializeCloudKitSchema() to match schemas between Core Data and CloudKit.
Added or deleted and attribute, call initializeCloudKitSchema() to update the CloudKit schema.
Renamed an attribute, call initializeCloudKitSchema() to update the CloudKit schema.
Etc.
If my assumption above is correct, calling the initializeCloudKitSchema() method during development would update the schema in CloudKit before the new app version is released in the AppStore, therefore creating an issue for existing users with previous versions of the app since they will not have the latest code but will be using the latest schema which contains the new attributes.
Can someone please share their method of handling schema updates in CloudKit after the app has been released to the AppStore?
Code:
do {
try container.initializeCloudKitSchema()
} catch {
print(error)
}
In my case, I didn't even need to run the initializeCloudKitSchema() method. Here is what I did that worked for me.
I tested locally with two devices and made sure everything was syncing as expected. This of course was done in Xcode within the sandbox environment using testing login accounts.
Then I went to the development CloudKit container and clicked on the Deploy Schema Changes.
Lastly I went and downloaded the app directly from the App Store on two different devices using a production/regular user account and tested it. Everything worked as expected.
Done
In theory, it looks like you need to deploy the schema to the Production CloudKit container once you're satisfied with the schema and the results in the testing environments by doing the above or possibly calling the initializeCloudKitSchema() which I didn't try.
Side notes: It looks like once you deploy your schema to the Production CloudKit container you no longer can delete or rename Entities or Attributes. Also, you will have to do the above every time you update the Core Data schema. Keep in mind that if you add or remove Entities or Attributes in Core Data, you must create a new version of the Core Data container to do what is called a light migration.
When you're developing on localhost, then you've got full access to a terminal that you can log anywhere you want. But, in a project, I work on (and am new to team collaboration as a whole) they use something called weavescope to view logs that developers have created at the time of coding.
Now what the difference between this and logging locally, everytime you'll create a change in the code, you gotta send a pull request, they approve it, and merge it, deploy it and we finally see it in the log. Now, sometimes the state of local and deployed things don't match and it really makes us wanna dynamically log on to the development server without having to go through all these cycles over again. Is there any solution already around that helps us insert some quick log statements without having to go through the routine PR, merge, deploy cycle?
EDIT: I think from discussions I had below, the tool I am looking for is more or less a logging statment code injection tool. A tool that would keep track of the logs I'm inserting into the production code, and on/off them at spin of a command.
This seems like something that logging levels can help with (unless I'm misunderstanding). Something I typically do is leave debug-level log messages on commonly problematic or complex functions, but change the logging level to something higher when I move out of local. Sometimes depending on the app and access these can be configured at the environment rather than in the build.
For example there are Spring libraries that will let you import a static logger, set the level of each message you log out. Then locally you can keep the level at DEBUG, in UAT the level can be INFO, and if you only want ERROR OR WARN messages in prod you can separate that too. At the time of deployment you can set what environment it is and store a separate app.properties or yml file for each environment storing the desired level for each
Of course there is a solution for fast pace code changes.
Maybe this kind of hot reloading is what you're looking for. This way you can insert new calls to a logger or console.log quickly.
Although it does come with a disclaimer from the author.
I honestly haven't looked into whether this method of hot reloading would provide stable production zero-downtime deploys, however my "gut feel" says don't do it. And production deployments are probably one area where we should stick to known, trusted procedures unless we have good reason.
I'm investigating by days with no results about this exception that my NextJS app is currently throwing, in particular when I try to open a single specific URL:
502: BAD_GATEWAY
Code: NO_STATUS_CODE_FROM_FUNCTION
ID: zrh1:4zx5l-1572269318137-64d401b5d058
Here's the screenshot:
Basically, I have on https://lucacattide.dev/about/en a page that this app should open. This is linked to a MongoDB third-party cloud API platform - Squidex - which is responsible to populate the page itself, via GraphQL queries. The app uses Apollo as GraphQL client. The app instead, is hosted on ZEIT.co serverless cloud, with Now 2.0 version.
During the development process, everything works fine. The page loads up and data is fetched in the right way. Notice that for development, I'm working on now-dev environment instead of a custom Express server, in order to reproduce the production one, as suggested by ZEIT itself.
The exception is being thrown on the production environment - the live one on the hosting platform, not on localhost; the main problem is that no errors are being shown on live logs or local development. So I'm literally going mad in inspecting the possible cause.
I've already tried to test the involved page, by splitting it in sections and trying to exclude child components, or focusing the inspection on the GraphQL query. But the first hasn't produced results and the latter works fine in every environment.
As last try, I deleted and re-created the back-end contents related to that page, because in the past I had a similar issue due to an old GraphQL edited schema that didn't reflected its modifications through the API - so in that case I was still receiving 502 errors. But this time it didn't worked.
Anyone could help me to understand what's going on, please?
Thanks everyone in advance
The issue was caused by an incompatibility between the d3-cloud library and the Now environment.
By replacing it with the react-wordcloud one, the error has been solved.
Thanks everyone for your assistance.
I have a MongoDB client in three EC2 instances and I have created a replica set. Last time I had a problem, of space constraint which stopped my mongod process, thereby halting the application and now in an instance couple of days back, some of my tables were gone from database, so I set logging and all to my database just to catch if anything like that happens again. In a fresh incident this morning I was unable to login to my system and that's when I found out that whole database was empty. I checked other SO question like this which suggest setting up a TTL.Which I haven't done at all.
Now how do I debug this situation and do a proper root cause analysis? I can't even find anything in my debug logs as well. The tables just vanished. How do I set up proper logging mechanism and how do I ensure that all my tables are never ever deleted again?
Today I got a mail from Amazon that I was probably running an unsecured version of MongoDB and that may have caused this issue. So who ever is facing this issue please go through the Security Checklist Provided by MongoDB. There are some points that are absolutely necessary in there.
1. Enable Access Control and Enforce Authentication
2. Encrypt Communication
3. Limit Network Exposure
These three are the core and depending upon how many people access your database you can Configure Role-Based Access Control.
These are all the things I have done. Before this incident I had not taken security that seriously but after I was hit by it. I made sure I have all the necessary precautions in place.
Hope this helps someone.
We have an app that is written in PHP. The front end uses javascript heavily. Generally, for normal applications that require page reloads, continuous deployment is not really an issue, because:
The app can be deployed with build tags: myapp-4-3-2013-b1, myapp-4-3-2013-b2, etc.
When the user loads a page (we are using the front controller pattern), we can inject the buildtag and the files are loaded from the app directory with the correct build tag.
We do not need to keep the older builds around for too long because as the older requests finish, they will move to the newer build tags.
The issue with database and user data being incompatible is not very high as we move people to the newer builds after their requests finish (more on this later).
Now, the problem with our app is that it uses AJAX heavily for smooth page loads. In addition, because there is no page refresh at all when people navigate through the application, people can keep their unsaved data in a their current browser session and revisit it as long as the browser has not been refreshed.
This leads to bigger problems if we want to achieve continuous deployment:
We can keep the user's buildtag in their session (set when they make the first request) and only switch to newer buildtags after the logout and login again. This is obviously bad, because if things like the database schema changes or the format of files to be written to disk changes in a newer build, there is no way to reconcile this.
We force all new requests to a newer build tag, but there is a possibility we change client side javascript and will break a lot of things if we force everyone with a session onto the new build tags immediately.
Obviously, the above won't occur with every build we push and hopefully will not happen a lot, but we want to build a fool proof process so that every build which passes our tests can be deployed. At the same time, we want to make sure that every deployed and test passing build does not inadvertently break in clients with running sessions cause a whole bunch of problems.
I have done some investigation and what google does (at least in google groups) is that they push a message out to the clients to refresh the application (browser window). However, in their case, all unsaved client side data (like unsaved message, etc) would be lost.
Given that applications that uses AJAX and local data are very common these days, what are some more intelligent ways of handling this that will provide minimal disruption to users/clients?
Let me preface this that I haven't ever thought of continuous deployment before reading your post, but it does sound like quite a good idea! I've got a few examples where this would be nice.
My thoughts on solving your problem though would be to go for your first suggestion (which is cleaner), and get around the database schema changes like this:
Implement an API service layer in your application that handles the database or file access, which is outside of your build tag environment. For example, you'd have myapp-4-3-2013-b1, and db-services folders.
db-services would provide any interaction with the database with a series of versioned services. For example, registerNewUser2() or processOrder3().
When you needed to change the database schema, you'd provide a new version of that service and upgrade your build tag environment to look at the new version. You'd also provide a legacy service that handles the old schema to new schema upgrade.
For example, say you registered new users like this:
registerNewUser2(username, password, fullname) {
writeToDB(username, password, fullname);
}
And you needed to update the schema to add the user's date of birth:
registerNewUser3(username, password, fullname, dateofbirth) {
writeToDB(username, password, fullname, dateofbirth);
}
registerNewUser2(username, password, fullname) {
registerNewUser3(username, password, fullname, NULL);
}
The new build tag will be changed to call registerNewUser3(), while the previous build tag is still using registerNewUser2().
So the old build tag will continue to work, just that any new users registered will have a NULL date of birth. When an updated build tag is used, the date of birth is written to the database correctly.
You would need to update db-services immediately, as soon as you roll out the new build tag - or even before you roll out the build tag I guess.
Once you're sure that everyone is using the new version, you can just delete registerNewUser2() from the next version of db-services.
This will be quite complicated to make sure that you are correctly handling the conversion between old API and new API calls, but might be feasible if you're already handling continuous deployment.