BigTable + HTTP triggered Cloud Functions

[arbesfeld]

I am using Cloud Functions with BigTable and seeing a perplexing error for HTTP triggered cloud functions that try to access the BigTable Admin API:

Cloud Bigtable Admin API has not been used in project r26584adb5f04cc0b before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/bigtableadmin.googleapis.com/overview?project=r26584adb5f04cc0b then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."

My project is not using that id, and I have tried initializing the BigTable with a correct projectId and confirmed that GCLOUD_PROJECT matches as well.

Here is the code that's failing:

const client = bigtable({
  zone: config.get('bigtable.zone'),
  maxRetries: 6,
}).instance(config.get('bigtable.instance'));

async function _getTable() {
  const table = client.table('events');

  try {
    const res = await table.get();
    return res[0];
  } catch (err) {
    console.warn(`Failed to get table: ${err.message}`);
    const res = await table.create({
      families: [{
        name: 'event',
        rule: {
          versions: 1,
        },
      }],
    });
    return res[0];
  }
}

This same exact code works in a Pub/Sub triggered cloud function.

Any ideas? Is it possible that there is some global that is being used for RPCs that go out from the HTTP cloud functions?

[stephenplusplus]

I'm not sure how it could be picking up another project ID. @jgeewax @omaray @callmehiphop @lesv heard of anything like this before?

[jgeewax]

@arbesfeld Any chance things change when you explicitly set the project ID in your code? (ie, projectId: 'my-project')

@jasonpolites Any chance you know why Cloud Functions would be blasting out the project ID?

[arbesfeld]

@jgeewax I tried that and didn't see any change in behavior. I also tried for multiple different projects, and see different "wrong" projectId in all cases. Also, I verified that the process.env.GCLOUD_PROJECT is indeed my own projectId.

The only thing that I could of would be that I'm running this at startup to add my own local modules to the NODE_PATH:

process.env.NODE_PATH = `${process.env.NODE_PATH}:local_modules`;
require("module").Module._initPaths();

[lesv]

I'm presuming you are talking about deployed cloud functions, and not running locally. (if local, you might wish to check gcloud config list).

Is there a reason you prefer to get a possibly dynamic value config.get, rather than the more static process.env.GCLOUD_PROJECT?

It might make sense to compare the config.get result with process.env.GCLOUD_PROJECT and log differences. It's sounding like there might be an issue of some kind.

[arbesfeld]

Thanks @lesv - we are using config with the node-convict library: https://github.com/mozilla/node-convict. This should be a static value. I compared both of these and see them both as being my own GCLOUD_PROJECT

[arbesfeld]

I discussed with the Google Support and this is not an issue with this library