Synchronous Call - wrapASync - Fibers - Need Advice


I’m quite new to Meteor but learning fast. I need to make a synchronous call to Smartsheet API and wait for the response. No matter how I code it, it doesn’t return a response or wait. I have been through every tutorial for wrapAsync, examples, that I can find but I must be missing something.

So here is a simple call that get’s me a list of workspaces and adds them to Mongo. Can someone point me in the direction I should go or help me with the code? Any help would be greatly appreciated.


	getWS: function(accessToken) {
		Fiber = Npm.require('fibers');

		const bound = Meteor.bindEnvironment((callback) => {callback();});

		var client = require('smartsheet');
		var smartsheet = client.createClient({
		  accessToken: accessToken,
		  logLevel: 'info'


			    .then(function(workspaceList) {
			    	  bound(() => {
			for (var i = 0, len =; i < len; i++) {


			    .catch(function (error) {



This will help you out:

You wrap your async code within runSync() and pass done(null, workspaceList). If you’ve set the runSync as a variable, you can access the workspaceList result after this step and insert your data into the database.

The reason to not insert data in the database inside the runSync is because of conflicts with fibers, so this would be the easiest solution (there are other ways, like putting the insert operation in a bound function and calling that function from within runSync)


I really cannot recommend meteorhacks:async. There is absolutely no need for using an unmaintained package to do something which can be done natively with async and await.

The smartsheet API uses Promises, so can be used directly in Meteor, including Fiber support.

Assuming your code is a Meteor Method:

async getWS(accessToken) {
  import client from 'smartsheet';
  const smartsheet = client.createClient({
    accessToken: accessToken,
    logLevel: 'info'


  const workspaceList = await smartsheet.workspaces.listWorkspaces();
  workspaceList.forEach(ws => {


I agree that if you can you should use async await, but to state that the package is unmaintained and therefore should not be used is deceiving imo. It’s just very simple and well written code using fibers (source code is only 80 lines). It hasn’t seen activity for 3 years because there’s no need to and probably never will. I also don’t see a drawback for using it in pretty much all use cases.

Again, in this and many other cases async await might the better solution, but don’t dismiss it just because it hasn’t been updated in the last month.


I just said I cannot recommend it. I did not say it shouldn’t be used. In my opinion (again), it’s a sledgehammer (even if only a small one) to crack a walnut.