No, this is expected behavior. The "size" of a volume gets a little tricky when SnapMirror is involved. When a volume is a VSM destination, it actually has two sizes: the size it was created with and the size reported by the "df" command. "df" will report the size of the source volume as of the time the last VSM update started (IOW, the destination volume looks like it's the size of the source volume). If the source volume grows, the next update will make the destination grow too.
This works to a point but if the source volume grows larger than the destination volume at the time the destination was created (that's the other size), the next VSM update will fail.
To avoid this situation, ProtMgr generally creates VSM destination volumes to be the size of the destination aggregate. It's actually a bit more complicated than that but the idea is to keep mirror updates from failing because we guessed wrong when creating the volume in the first place.