Yeah, using the timer to kick each search was my next attempt at a work-around.  I don't see why it would be needed, as the other sync APIs (do_syncsource) that callback with a completion status allow you to then kick off the next model sync from the callback just fine.  It is the same underlying sync plumbing for both, so Timer feels kludgey to me.

I've got a model (Item) that gets populated via a call to Item.search
What is "search"? Did you mean "find"?

  In the callback, when @params['status'] is complete, a second search against Item is initiated.
Oh, do you mean that you have defined a method called "search" in a controller for a model called Item?  Not giving us much to go on here...

Your problem is with your controller, not with Rhom.

Each request to the Rhodes server is queued. Rhodes spins-up a controller instance, runs the controller method, the method eventually returns, and the controller instance is destroyed. Each request gets a new controller instance, with instance variables set with @params, etc. from that request.

Callbacks are really just server requests. They are queued just like any other server request.

To queue a request from within a controller instance, you can either use Network, passing a callback URL, or else use Rho::Timer with an interval of 0.

If this has something to do with your "one-way-synchronization" problem, might I suggest looking at using lambda callbacks? That's my preferred way of handling Rho::Network callbacks in 5.x. You don't need to use a controller. You can use lambda callbacks to implement asynchronous network operations without needed to use a controller. (In fact, I just finished up a "one-way sync" implemented in a stand-alone module along with a mixin that gets included in those models that participate in an API, using lambda callbacks. I don't delete records after they have been uploaded, since our requirement is a bit different than yours.