OK. now we see that the dynamicObject is broken somehow

Pls. forget "store it as it is" all you store is the oref (a pointer to a local structure) with no persistent storage behind.

so you don't get an error if you just apply  %ToJSON()  ???

 If your version is before 2016.2  than .$toJSON() would be the right method

You didn't indicate the line you get the error.
anyhow the message is clear:
Either classObj or dynamicObject is not what you expect it to be.
If you test from Terminal you can use

ZWRITE classObj
ZWRITE dynamicObject

to see what they are.

otherwise, you may comment out one line and see if it still breaks e.g.

So you see what happens.  I expect:  my dynamicObject = 0

So you see where you have to investigate further

is it defined that way?
Property Test as %String (MAXLEN="") ;

ATTENTION - default MAXLEN = 50 !!!!!

This might look odd but try

 
so you see if the issue is your property  
or your dynamic Object. as there are 2 objects in the command.
the only thing %String is checked against is Length. 
otherwise. if %ToJSON() fails your dynamic object is broken somehow

Peter,
I have the same problem. (and some more others). It's good not to feel alone. 

Robert

If you check it in the same process it's of course there as you are still in the same local partition (environment).
but you need it in your message that gets handled by some other process that has no access nor idea about your local environment.

which is the essential concept of all those message structures.

You can't just set the dynamic object (exactly the oref) to  %String.
You place than just a reference of a local structure to your message.  That's useless.
you need to 

Set classObj.Test = DynamicObject.%ToJSON()

Now you have your string that gets persisted and is part of your message.

Suggested reading: Converting Dynamic Entities to and from JSON​

Have you tried to set it back to %String manually?
There should be no issue from Ensemble side
 

is it persistent across different browsers ?

IF YES -> our problem,
OR do you see different cut off lengths.
 I especially distrust IE !
 

I added it just to the end. But thas nit important.

Did you also add at the end this: ??

If this is missing the class also doesn't compile. 
the name of the global for streams is not important.

BT: What error did you get ?

- you have

Parameter CONNECTION = "canreg,NOCREATE";

- so the name of your Gateway definition is canreg 
- you have no storage for streams defined.
Strange but might be an issue of Caché version version issue.
in 2016.2 it just doesn't compile without.
- more strange is this:

Index MainIndex On null [ IdKey, PrimaryKey ];

The property null doesn't exist in your class.
Without a property null  it doesn't compile for me.

adding manually the missing Storage section and 

Property null As %Integer;

let it compile for me. 

Though this may be a temporary fix I distrust your Link Wizard.
Eventually, you should contact WRC  to investigate the reason.

You are right!  
And I'm not aware of a different behavior.  Except:  oops!

I just can guess for possible reasons
- dependencies in parallel compiling 
- some kind of complex or circular "CompileAfter" constructs 

those things often vanish at 2nd compile with freshly loaded classes.  (Hard to reproduce.)

only 1 .int in %SYS uses "oops:"
MIRRORCOMM.int(2845): if $zb(+$SYSTEM.Mirror.DebugFlags(),1,1) do $zu(9,"","oops: jrn.log has incorrect entry, exp("_newpath_") logentry("_jrnfname_"), file num-"_mirfilecnt)
 

 could be an indicator to some MIRROR issue

Yes.  Connect to Mirror using SQLgateway.
Link Procedure And then just to a SELECT or CALL.
The code has, of course, to be prepared already on Mirror.

if ever this should be of practical use
then I'd suggest to move such a "everybody's darling" routine to %SYS and name it %zYJM