Some funk in Unity with Helpers.Send vs Operations.Send

Help Developers
,
#1

Hi peeps :waffle:

I’ve been working on my lil unity fork and I’ve been trying to tackle this async issue where unity is stuck in an editor loop when trying to close or start a new play session after I send something to a speckle stream :crying_cat_face:. but! I’ve discovered the issue and wanted to get some input from the speckle-pros!

The Sender from speckle-unity sends off data using the Helpers.Send instead of the typical Operations.Send. I switched out the helper method thinking I was keeping things up to date with the typical speckle logic, but when I switch out the helper method and try to send something that’s when unity goes into a never ending loop. I’ve done some testing around with different ways of handling that task but nothing seems to do the trick and when checking the threads on the unity profiler I can’t seem to locate any active tasks related to that send, so my assumption now is that something funky is happening on the Speckle side that Unity doesn’t know how to clean up manually.

I skimmed over both send calls to see if I could discover anything but no luck, could someone help me understand the difference between the two methods? :thinking: and can the unity connector continue using this function or will it be deprecated?

I thought about opening an issue for this, but since Helpers.Send works I thought a post would be better. @Jedd let me know if you want this tracked as an issue :smiley:

#2

Hey David, can you share your implementation as well? Might just have to do with how the tasks are awaited etc.

The helper method btw is not going away, it’s been thought as a simpler alternative to using the full Operations.Send code, especially if in a scripting environment.

1 Like
#3

For sure, below is the snippet. Good to know about the helper method, I’ll rely on that for now.

      try
      {
        var data = ConvertRecursivelyToSpeckle(gameObjects);
        Task.Run(async () =>
        {
          var res = await Operations.Send(data, token, new List<ITransport>() { new ServerTransport(account, streamId) });

          onDataSentAction?.Invoke(res);
        });
      }
      catch (Exception e)
      {
        throw Debug.LogException(new SpeckleException(e.Message, e, true, SentryLevel.Error));
      }
#4

Mhh well, I cannot really explain it, as you just unpacked the helper method code there!

1 Like
#5

phew, I was wondering if I was just going crazy for a second. I figure there might be something getting stuck in the unity threads that doesn’t get cleaned up correctly. I notice that the helper method uses
Tracker.TrackPageview or Analytics.TrackEvent, maybe those need to be handled if I end up using Operations.Send?

#6

This week, I noticed some odd behaviour with unity loosing track of threads with long send operations.
The behaviour I was seeing is with large streams, neither OnErrorAction, or OnDataSentAction were being called.

Does this sound related?
I’ll do some investigating.

1 Like
#7

I tried sending a simple cube and got the same error, so i don’t think it has anything to do with the size. I also played around with the actions to see if that was doing something strange, but no luck :frowning:

#8

These are tasks that don’t need to be awaited, you can try commenting them out and see if it makes any difference?

#9

:frowning: doesn’t seem to help

#10

Hi David,

Me and @cristi have done some investigation, and we can reproduce some pretty major issues with Sending from Unity. :cry:
We have had some limited success disabling the attaching of SpeckleProperties since this was leading to super large payloads, but this didn’t totally solve the issue.
We are a little stumped, as this is quite hard to debug, but I’m going to try and create some bare-bones tests that should help isolate the problem.

I’ll keep you informed as to our progress, but it does seem that the current main branch is affected.
Thanks for bringing this to our attention, and we hope to solve this shortly.

1 Like
#11

Thanks Jedd for the update! I appreciate you and @cristi tackling this issue. Please let me know if there is anyway for me to help.

fwiw I’ll drop a couple of other notes around troubleshooting that I did, maybe they will spark something :sparkles:

  • I tried calling Operations.Send with an empty base object from both runtime and edit mode, both resulted in the same error.
  • I was wondering if the async calls in unity were acting totally different than most c# application, so I tried relying on UniTask library for all awaitable functions. This helped with receiving and creating gameObjects, but didn’t solve the issue with sending.
#12

@Jedd @cristi I discovered a way to fix this editor break with the Operations.Send call. If you set disposeTransports: true the error no longer occurs and sends out data as it should :rocket: . I tried toggling all the other parameters available while keeping this set to default(false) but the issue was only fixed with disposing of those lil babies

I took a peek at what happens when toggling the disposal and realized it was a simple .Dispose( ) call on the transport. Handling the disposal manually also resulted in success with making this issue vanish :mage:

Would there be a reason for us to not want to dispose of those transports? Are transports suppose to be reused :recycle: ?

1 Like