A Form Type isn’t found or doesn’t appear to behave as the latest edited version should

[su_note note_color=”#acf596″]This topic applies to release 6.2 onwards.[/su_note]
You may encounter either of these problems:

  1. A Server Task executes a Form Type but execution fails with a “Form Type Not Found” message being added to the event log.
  2. You edit a Form Type and save the changes, but when the Form Type is next executed by a Server Task, the changes you made don’t seem to have any effect and the Form Type goes on behaving as it did before the edit.

Both of these can have the same cause, which is related to preparing the scripts in a Form Type for execution, or “linking” them (see “Scripting internals” in the help for more details of how the scripts in a Form Type are linked). Although it’s rare, it is possible to introduce an error which only arises at link time, for example by having an Include Script which contains a function definition, and including that script into a Form Type somewhere other than the Globals script, for example in the Prep script. Because functions can only be defined in the Globals script, this causes an error when the scripts are linked and the linker finds that it now has a function definition in the Prep script, and this makes the linking process fail because the Form Type is not valid to be executed.

The system can’t prevent you doing this because the Form Type and the Include Script are separate entities and you can change either without the other, so for example there may not be a function in the Include Script at the time when you edit and test the Form Type using that Include Script, but you later edit the Include Script and add the function. So the Form Type was valid when you last tested it, but suddenly it isn’t any more because as soon as the change to the Include Script reaches the Task Despatcher’s cache it will relink the Form Type with the new version of the script and that will cause the error.

However Dashboard can’t warn you about this when you edit the Include Script either because it could be used in several different Form Types in different places, so it may still be valid in those Form Types where you used it in the Globals script, but not in other Form Types where you placed it in other scripts, so whether it’s valid depends on where and how you use it. It could take a prohibitively long time to scan every Form Type on your system to see whether it uses this Include Script, then check whether it will still be valid after the update, so the system doesn’t do that. This means the bottom line is that it’s up to you to make sure that each combination of Include Script and Form Type will be valid after any edit you do, which is particularly important if you have many Form Types using the same Include Script and you may have forgotten that one of them uses it in a different place to all the rest.

Why are there two different problems I might see for the same error?

If you do introduce this sort of error, you will hit either problem 1 or problem 2 above depending on when you did it. If the problem is already there when the Task Despatcher service starts up, then the Form Type that fails to relink will never be added to the service’s configuration cache in the first place, which means that any task which tries to execute it will cause a “Form Type Not Found” error in the event log.

On the other hand, if everything was ok to start with and the Form Type was working, then it will have been added to the Task Despatcher service’s cache at startup. If you then edited either the Form Type or the Include Script and introduced the error while the service was already running, the new version of the Form Type won’t make it into the cache, but the old copy that was already there may remain in the cache instead of being replaced because the error will abort that replacement process (whether the old version gets removed depends on exactly where the error arises, so sometimes the Form Type may be missing afterwards, other times not). If the old Form Type does remain in the cache, a Server Task which uses the Form Type would execute successfully but the version of the Form Type that gets executed would be the one from before your changes, so you may notice that your changes don’t seem to have had any effect.

Regardless of whether it’s scenario 1 or 2, there would always be a “Failed to relink Form Type” error in the event log, either when the Task Despatcher service’s cache is being populated at startup, or just after you edited the Form Type / Include Script. So if you think there may be a problem it’s always worth searching the event log for, say the last half day (or further back if the service has been running longer), looking for “relink” in the “Details” field to see if the failure is there.

Bear in mind that if the Form Type is missing from the cache you’ll get a “Form Type Not Found” error in the event log every time a task tries to execute it, so there may be many of those messages but they don’t absolutely confirm why the Form Type is missing as there could be other reasons. The relink was only done once when the Form Type was being added to the cache or updated, so you won’t see a “Failed to relink Form Type” error each time a task tries to execute it. That’s why you need to search back to the time when that message would have been logged.

Another approach is to open the suspect Form Type in Dashboard and do a preview run to see if any errors come up. If the linking fails, it will appear as a pop-up error message so you won’t be in any doubt. Bear in mind though that if you’ve edited an Include Script recently you may need to use the “Refresh Caches” button in the Form Type ribbon to make sure that you have up to date copies of all the Include Scripts before you do the preview run. So long as you do have up to date scripts, if the preview run executes without errors in Dashboard then so should the Form Type when a Server Task executes it.