FAQ & Common Errors🔺
By default, the script is smart and will use a page token to improve the efficiency of pulling events from GCal, such that it won't pull events that it doesn't need to. However, if the page token is invalid such as during initial setup (since one has never been generated) or if the user forces a full sync, the script will instead ask the GCal API for all the events that fit the parameters, regardless of if the event is new or has been recently updated. Due to the script now needing to parse through a much larger number of events than when compared to normal operation, full sync operations are prone to execution timeout errors.
Typically, a user may wish to manually trigger a full sync for troubleshooting, or to reset and update the max and min event fetch dates.
Note that when a full sync is triggered, the previous page token is discarded. Furthermore, the max and min event fetch dates are updated. The origin of the relative dates will be reset to the execution time. The constants RELATIVE_MAX_DAYS and RELATIVE_MIN_DAYS will also be fetched and utilized (they are not relevant during normal operation).
Note that if the user manually triggers a full sync, synchronization operations in the direction of Notion to GCal are not done to ensure that the script has as much execution time as possible to perform the full sync.
To manually trigger a full sync, go to the top bar of the Google Apps Script project editor. Select fullSync in the drop-down menu, next to the Debug button. Afterwards, either click the Run or Debug button to run or debug the full sync execution.
Make sure that your Notion calendar is showing by Date, not sync date! Sync date is an internal property used by the script that you mostly do not care about and should just leave it alone. The date property you want to use for your calendar is Date.
Try doing a full sync. Set the constant FULL_SYNC to true and then manually run the script as normal. This refreshes the sync token such that the GCal API will give the script information about all the events in the calendars, not just the ones it thinks haven't been updated yet. Remember to reset FULL_SYNC to false after your sync run because keeping it on can cause issues with events showing up later on if you have a lot of events and is also just less efficient.
The console says that some event is cancelled, but then says that it can't find the corresponding page in Notion.
This is usually harmless. Most of the time it is caused by a weird quirk in GCal and its sync token and deleted/cancelled events. Typically using the GCal sync token means that the GCal API will only list new events and event updates that it thinks it hasn't ever told the script before in previous runs. However, for some reason, the API sometimes will return deleted events for multiple runs. Since the page most likely has been archived on the first time the cancellation showed up, the script won't be able to find the event and thus will just ignore it.
Other times, the event was just created and then deleted before the script had a chance to synchronize. For instance, on the first run or a full sync, the API will list events that were deleted before, but these events may have never been pushed to the Notion database in the first place. This situation is also harmless.
You may have too many events that are being synchronized such that Google Apps script hit its limit and decided to stop running the script. Unfortunately, there isn't much that can be done about this.
There are a few things you can try doing. Firstly, try synchronizing only one calendar at a time from GCal to Notion. Add calendars one at a time to the calendar dictionary. Unfortunately, this only really works if your events are spread out between calendars. Split events up into more calendars. The first full sync will be the most painful as afterwards, the script only takes into consideration events that have been updated or have been created since the last run.
A different workaround is to restrict the timeframe that the script will fetch events from your GCal calendar. See the RELATIVE_MAX_DAY option on the extra customization page for more info. Unfortunately, by limitation of the GCal API, this timeframe can only be set in full_sync mode. It cannot be modified in non full_sync mode, and the timeframe is not a shifting timeframe, meaning the max date does not shift forward as time passes.
By default, per calendar, the script will grab all events, from 30 days prior to the last full sync, to 5 years from the last full sync. Recurring events seems to be limited up to 30 reptations. These settings can be tinkered with in the script, but be warned, there are hard limits set by the GCal API! If you have too many events to be synchronized, you may run into an execution timeout error, where the script doesn't get to finish before Google Apps script decides to give up on it.
See the extra customization page for instructions on how to modify these settings.
This is a known thing relating to time zones being funky in Google apps script. Some people had success in fixing it by changing their project to a different "timezone" that has the same GMT offset such that the actual time doesn't really change in reality. You can do this in the project settings using their dropdown. More specific options become available by enabling Show "appsscript.json" manifest file in editor in the settings, and then changing the timeZone field of appscript.json using the editor. Time zones that seem to work include but are not limited to America/New_York and Etc/GMT+1.
This error is most commonly caused by the database being setup incorrectly. The name of your column is correct, but the data type for that column was incorrectly set. Pay attention to the error message for information about what column is causing issues, and the data type that is expected for that column.
An alternative/confounding cause for this error is caused by improper modification of the expected column names in main.js. Make sure that if you modify the names associated with the columns, that the column still has the correct data type as indicated by the setup instructions. Match the name of the constant in the script, to the data type of the instructions. Then make sure that the assigned value to that constant in the script is the name of a column with a matching data type!
This indicates something went wrong either with the setup of the DATABASE_ID script property or the script's parsing of said property. Double check the corresponding section in the setup instructions. Pay special attention to the value you are assigning to the script property DATABASE_ID. If you are sure that the value you are assigning the property is correct, then your database's share URL may be a strange edge case the script doesn't recognize. For now, instead of using a share link to the database as the property value, use the actual database ID. You can parse this yourself by examining the share URL. It should be the string of characters between notion.so/ and ?.
At this point it should work, but you should still open an issue and report this as a potential bug. In the issue report, please describe the structure of the database URL you had initially used. For privacy, you don't need to share the actual share link to your database, but we do need at least some information about the URL structure you are utilizing.