# Requesting Project Scan **URL:** \ **Category:** 3rd Party Modules\ **Tags:** ignition83\ **Created:** [January 12, 2026, 7:07pm UTC](https://forum.inductiveautomation.com/t/requesting-project-scan/113224 "2026-01-12T19:07:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![aaronrai24](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/aaronrai24/32/87248_2.png) [@aaronrai24](https://forum.inductiveautomation.com/u/aaronrai24)\ **Post date:** [January 12, 2026, 7:07pm UTC](https://forum.inductiveautomation.com/t/requesting-project-scan/113224/1 "2026-01-12T19:07:44Z")
Im working on a third party tool that allows editing of files outside of the designer, after editing and saving I need to trigger a project scan (data/api/v1/scan/projects) so that the latest changes are picked up but this raises a few questions: - Do I _have to_ acquire a project scan lock(data/api/v1/scan-lock/projects) before requesting a project scan? - Is project scanning asynchronous? The reason I ask this is because we have a module that will update the designer project after receiving a notification from the gateway but I don’t want to create a race condition where the designer project updates before the gateway is done with its project scan. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [January 12, 2026, 7:11pm UTC](https://forum.inductiveautomation.com/t/requesting-project-scan/113224/2 "2026-01-12T19:11:43Z")
It's asynchronous. The scan lock is optional. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [January 12, 2026, 7:24pm UTC](https://forum.inductiveautomation.com/t/requesting-project-scan/113224/3 "2026-01-12T19:24:05Z")
> [@aaronrai24](#): > > I don’t want to create a race condition where the designer project updates before the gateway is done with its project scan. You can `GET` the same endpoint to check whether a scan is already running. Note that no matter what you do, there's no (supported) way to force any open designers to _pull_ the updated project from the gateway, so this may never get the user experience you really want. ---
**Author:** ![andrewdhunt7](https://avatars.discourse-cdn.com/v4/letter/a/d6d6ee/32.png) [@andrewdhunt7](https://forum.inductiveautomation.com/u/andrewdhunt7)\ **Post date:** [February 11, 2026, 9:05pm UTC](https://forum.inductiveautomation.com/t/requesting-project-scan/113224/4 "2026-02-11T21:05:36Z")
Is there a supported way to _inform_ Designer sessions that a resource has been changed, similar to what happens when another user’s Designer session publishes a Save? If there is no need to actually force the pull that is I have GitHub Actions set up that (on update of remote repo under certain conditions) update the local repo on a Docker Host, uses mapping YAML docs to push the called for files into the appropriate directories of the gateways running in Docker containers, and ping the scan APIs of each gateway to tell Ignition that there are new resources. If I click the refresh icon in the Designer, everything is there just fine. But you would have had to know that things had changed, as it didn’t throw that utility message in the bottom toolbar If this is possible, is it only via a custom module that makes use of some designer class? Or is it possible just with native 8.3 functionality without having to have a Designer session run? ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [February 11, 2026, 10:49pm UTC](https://forum.inductiveautomation.com/t/requesting-project-scan/113224/5 "2026-02-11T22:49:09Z")
Preemptive disclaimer: This is well in the "implementation detail" weeds - we don't guarantee something like this will continue working indefinitely, but for all of 8.3 and with some minor adjustments 8.1, you could take advantage of the same mechanism we currently use for designer conflict messages. These are "push notifications" delivered to each active session when one particular designer makes a change. The message class is `com.inductiveautomation.ignition.designer.concurrency.DesignerProjectUpdate`, and the notification message is sent to all active designers running the given project: ```java for (ClientReqSession s : sessions) { s.addNotification( PLATFORM_MODULE_ID, DesignerConcurrencyMessage.PROJECT_UPDATE, update, PushNotificationSerializer.ofString(DesignerConcurrencyMessage.GSON::toJson)); } ``` If you pushed those updates from another module, the designer wouldn't know the difference and you'd get the exact same behavior for end users. EDIT: For what it's worth, I just created an internal ticket IGN-15468. We should just refactor the way this "a resource update was detected" logic happens so that it detects _any_ kind of change, not just changes from a running designer instance. ---
**Author:** ![andrewdhunt7](https://avatars.discourse-cdn.com/v4/letter/a/d6d6ee/32.png) [@andrewdhunt7](https://forum.inductiveautomation.com/u/andrewdhunt7)\ **Post date:** [February 19, 2026, 2:30am UTC](https://forum.inductiveautomation.com/t/requesting-project-scan/113224/6 "2026-02-19T02:30:02Z")
Forgot to hit reply, but thanks for the information and also thank you for the ticket submission. That would certainly be a nice to have with how our current workflow is structured where we essentially just have services that update the file system in the background. We’re only in a Dev environment right now, but as we move along and have various designers open across environments with someone testing in QA, someone testing in staging, someone hotfixing in production, etc., anything that increases clarity will go a long way