MongoMemoryServer.create unusually slow in v10

Hi there 👋 !
Versions

NodeJS: 20.12.1
mongodb-memory-server-*: 10.0.0 and 10.0.1
mongodb(the binary version): 0.0.0 (default)
mongodb(the js package): (irrelevant)
system: MacOS 14.1.1 (23B81)

package: mongo-memory-server
What is the Problem?
I've been using this lovely package for a while for unit tests (thank you so much 🙏). I recently upgrade to the v10 (well, 10.0.1) and noticed my test were significantly longer. I realised that the startup of the in-memory mongo server took much more than usual.
There's always a "cold start" for the first run, but usually in v9 my mac would have the server ready in 80-90ms. Now it takes between 900ms and 1300ms before the promise resolves.
Code Example
// test/mongo.spec.js
const { MongoMemoryServer } = require('mongodb-memory-server');

describe('test mongo-server', () => {
    // NB: the first run of this fails on my side with either v9 or v10, but subsequent runs in v9 are <100ms for me
    it('should not take more that 200ms', async () => {
        const start = Date.now();
        const server = await MongoMemoryServer.create();
        const ellapsed = Date.now() - start;
        await server.stop();

        expect(ellapsed).toBeLessThan(200);
    });
});

FYI the package.json:
{
  "name": "test-mongo-in-memory",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "jest"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "description": "",
  "dependencies": {
    "jest": "^29.7.0",
    "mongodb-memory-server": "^9.4.1"
  }
}

Debug Output

Debug Output

  MongoMS:ResolveConfig Debug Mode Enabled, through package.json +0ms
  MongoMS:MongoMemoryServer create: Called .create() method +0ms
  MongoMS:MongoMemoryServer Mongo[unknown]: start: Called .start() method +0ms
  MongoMS:MongoMemoryServer Mongo[unknown]: _startUpInstance: Called MongoMemoryServer._startUpInstance() method +0ms
  MongoMS:MongoMemoryServer Mongo[unknown]: getStartOptions: forceSamePort: false +0ms
  MongoMS:DryMongoBinary generateOptions +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Generating Download Path, preferGlobal: "true" +1ms
  MongoMS:DryMongoBinary generatePaths {
  version: '7.0.11',
  downloadDir: '',
  os: { os: 'darwin' },
  platform: 'darwin',
  arch: 'arm64',
  systemBinary: ''
} +0ms
  MongoMS:DryMongoBinary getBinaryName +1ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Paths: {
  homeCache: '/Users/my-user-name/.cache/mongodb-binaries/mongod-arm64-darwin-7.0.11',
  modulesCache: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11',
  relative: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/mongodb-binaries/mongod-arm64-darwin-7.0.11',
  resolveConfig: ''
}  +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Found binary in modulesCache: "/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11" +0ms
  MongoMS:GetPort getFreePort: found free port 61168, in cache and not custom: false +0ms
  MongoMS:MongoMemoryServer Mongo[unknown]: _startUpInstance: Creating new MongoDB instance with options: {
  instance: {
    port: 61168,
    dbName: '',
    ip: '<IP_ADDRESS>',
    storageEngine: 'wiredTiger',
    replSet: undefined,
    dbPath: '/var/folders/pg/t48q3kmx7l1_2_t4nzfd7zf80000gn/T/mongo-mem-TpDc3wXVWxc8',
    tmpDir: '/var/folders/pg/t48q3kmx7l1_2_t4nzfd7zf80000gn/T/mongo-mem-TpDc3wXVWxc8',
    keyfileLocation: undefined,
    launchTimeout: undefined,
    args: undefined,
    auth: false
  },
  binary: undefined,
  spawn: undefined
} +4ms
  MongoMS:MongoInstance create: Called .create() method +0ms
  MongoMS:MongoInstance Mongo[61168]: start +0ms
  MongoMS:MongoBinary getPath +0ms
  MongoMS:DryMongoBinary generateOptions +2ms
  MongoMS:DryMongoBinary generateDownloadPath: Generating Download Path, preferGlobal: "true" +0ms
  MongoMS:DryMongoBinary generatePaths {
  version: '7.0.11',
  downloadDir: '',
  os: { os: 'darwin' },
  platform: 'darwin',
  arch: 'arm64',
  systemBinary: ''
} +0ms
  MongoMS:DryMongoBinary getBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Paths: {
  homeCache: '/Users/my-user-name/.cache/mongodb-binaries/mongod-arm64-darwin-7.0.11',
  modulesCache: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11',
  relative: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/mongodb-binaries/mongod-arm64-darwin-7.0.11',
  resolveConfig: ''
}  +1ms
  MongoMS:DryMongoBinary generateDownloadPath: Found binary in modulesCache: "/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11" +0ms
  MongoMS:MongoBinary getPath: MongoBinary options: {
  "version": "7.0.11",
  "downloadDir": "/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server",
  "os": {
    "os": "darwin"
  },
  "platform": "darwin",
  "arch": "arm64",
  "systemBinary": "",
  "checkMD5": true
} +1ms
  MongoMS:DryMongoBinary locateBinary: Trying to locate Binary for version "7.0.11" +0ms
  MongoMS:DryMongoBinary generateOptions +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Generating Download Path, preferGlobal: "true" +0ms
  MongoMS:DryMongoBinary generatePaths {
  version: '7.0.11',
  downloadDir: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server',
  os: { os: 'darwin' },
  platform: 'darwin',
  arch: 'arm64',
  systemBinary: ''
} +0ms
  MongoMS:DryMongoBinary getBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generatePaths: resolveConfigValue is not empty +1ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Paths: {
  homeCache: '/Users/my-user-name/.cache/mongodb-binaries/mongod-arm64-darwin-7.0.11',
  modulesCache: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11',
  relative: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/mongodb-binaries/mongod-arm64-darwin-7.0.11',
  resolveConfig: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11'
}  +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Found binary in resolveConfig (DOWNLOAD_DIR): "/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11" +0ms
  MongoMS:DryMongoBinary locateBinary: running generateDownloadPath +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Generating Download Path, preferGlobal: "true" +0ms
  MongoMS:DryMongoBinary generatePaths {
  version: '7.0.11',
  downloadDir: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server',
  os: { os: 'darwin' },
  platform: 'darwin',
  arch: 'arm64',
  systemBinary: ''
} +0ms
  MongoMS:DryMongoBinary getBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generatePaths: resolveConfigValue is not empty +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Paths: {
  homeCache: '/Users/my-user-name/.cache/mongodb-binaries/mongod-arm64-darwin-7.0.11',
  modulesCache: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11',
  relative: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/mongodb-binaries/mongod-arm64-darwin-7.0.11',
  resolveConfig: '/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11'
}  +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Found binary in resolveConfig (DOWNLOAD_DIR): "/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11" +0ms
  MongoMS:DryMongoBinary locateBinary: found binary at "/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11" +1ms
  MongoMS:MongoBinary getPath: Mongod binary path: "/Users/my-user-name/Documents/Temp/test-mongo-in-memory/node_modules/.cache/mongodb-memory-server/mongod-arm64-darwin-7.0.11" +2ms
  MongoMS:MongoInstance Mongo[61168]: start: Starting Processes +3ms
  MongoMS:MongoInstance Mongo[61168]: _launchMongod: Launching Mongod Process +0ms
  MongoMS:MongoInstance Mongo[61168]: prepareCommandArgs +0ms
  MongoMS:MongoInstance Mongo[61168]: prepareCommandArgs: final argument array:["--port","61168","--dbpath","/var/folders/pg/t48q3kmx7l1_2_t4nzfd7zf80000gn/T/mongo-mem-TpDc3wXVWxc8","--storageEngine","wiredTiger","--bind_ip","<IP_ADDRESS>","--noauth"] +0ms
  MongoMS:MongoInstance Mongo[61168]: _launchKiller: Launching Killer Process (parent: 50137, child: 50170) +2ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:40.640+02:00"},"s":"I",  "c":"NETWORK",  "id":4915701, "ctx":"thread1","msg":"Initialized wire specification","attr":{"spec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":21},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":21},"outgoing":{"minWireVersion":6,"maxWireVersion":21},"isInternalClient":true}}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:40.640+02:00"},"s":"I",  "c":"CONTROL",  "id":23285,   "ctx":"thread1","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}"" +106ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:40.642+02:00"},"s":"I",  "c":"NETWORK",  "id":4648602, "ctx":"thread1","msg":"Implicit TCP FastOpen in use."}"" +2ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:40.643+02:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"thread1","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"TenantMigrationDonorService","namespace":"config.tenantMigrationDonors"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:40.643+02:00"},"s":"I",  "c":"REPL",     "id":5123008, "ctx":"thread1","msg":"Successfully registered PrimaryOnlyService","attr":{"service":"TenantMigrationRecipientService","namespace":"config.tenantMigrationRecipients"}}"" +1ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:40.643+02:00"},"s":"I",  "c":"CONTROL",  "id":5945603, "ctx":"thread1","msg":"Multi threading initialized"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:40.643+02:00"},"s":"I",  "c":"TENANT_M", "id":7091600, "ctx":"thread1","msg":"Starting TenantMigrationAccessBlockerRegistry"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:40.643+02:00"},"s":"I",  "c":"CONTROL",  "id":4615611, "ctx":"initandlisten","msg":"MongoDB starting","attr":{"pid":50170,"port":61168,"dbPath":"/var/folders/pg/t48q3kmx7l1_2_t4nzfd7zf80000gn/T/mongo-mem-TpDc3wXVWxc8","architecture":"64-bit","host":"Remis-MacBook-Pro.local"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:40.643+02:00"},"s":"I",  "c":"CONTROL",  "id":23403,   "ctx":"initandlisten","msg":"Build Info","attr":{"buildInfo":{"version":"7.0.11","gitVersion":"f451220f0df2b9dfe073f1521837f8ec5c208a8c","modules":[],"allocator":"system","environment":{"distarch":"aarch64","target_arch":"aarch64"}}}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:40.643+02:00"},"s":"I",  "c":"CONTROL",  "id":51765,   "ctx":"initandlisten","msg":"Operating System","attr":{"os":{"name":"Mac OS X","version":"23.1.0"}}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:40.643+02:00"},"s":"I",  "c":"CONTROL",  "id":21951,   "ctx":"initandlisten","msg":"Options set by command line","attr":{"options":{"net":{"bindIp":"<IP_ADDRESS>","port":61168},"security":{"authorization":"disabled"},"storage":{"dbPath":"/var/folders/pg/t48q3kmx7l1_2_t4nzfd7zf80000gn/T/mongo-mem-TpDc3wXVWxc8","engine":"wiredTiger"}}}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:40.644+02:00"},"s":"I",  "c":"NETWORK",  "id":5693100, "ctx":"initandlisten","msg":"Asio socket.set_option failed with std::system_error","attr":{"note":"acceptor TCP fast open","option":{"level":6,"name":261,"data":"00 04 00 00"},"error":{"what":"set_option: Invalid argument","message":"Invalid argument","category":"asio.system","value":22}}}"" +1ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:40.644+02:00"},"s":"I",  "c":"STORAGE",  "id":22315,   "ctx":"initandlisten","msg":"Opening WiredTiger","attr":{"config":"create,cache_size=15872M,session_max=33000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,remove=true,path=journal,compressor=snappy),builtin_extension_config=(zstd=(compression_level=6)),file_manager=(close_idle_time=600,close_scan_interval=10,close_handle_minimum=2000),statistics_log=(wait=0),json_output=(error,message),verbose=[recovery_progress:1,checkpoint_progress:1,compact_progress:1,backup:0,checkpoint:0,compact:0,evict:0,history_store:0,recovery:0,rts:0,salvage:0,tiered:0,timestamp:0,transaction:0,verify:0,log:0],"}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.298+02:00"},"s":"I",  "c":"WTRECOV",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":{"ts_sec":1727444501,"ts_usec":298066,"thread":"50170:0x1d6f0dec0","session_name":"txn-recover","category":"WT_VERB_RECOVERY_PROGRESS","category_id":30,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"recovery log replay has successfully finished and ran for 0 milliseconds"}}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.298+02:00"},"s":"I",  "c":"WTRECOV",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":{"ts_sec":1727444501,"ts_usec":298172,"thread":"50170:0x1d6f0dec0","session_name":"txn-recover","category":"WT_VERB_RECOVERY_PROGRESS","category_id":30,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"Set global recovery timestamp: (0, 0)"}}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.298+02:00"},"s":"I",  "c":"WTRECOV",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":{"ts_sec":1727444501,"ts_usec":298189,"thread":"50170:0x1d6f0dec0","session_name":"txn-recover","category":"WT_VERB_RECOVERY_PROGRESS","category_id":30,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"Set global oldest timestamp: (0, 0)"}}}"" +654ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.298+02:00"},"s":"I",  "c":"WTRECOV",  "id":22430,   "ctx":"initandlisten","msg":"WiredTiger message","attr":{"message":{"ts_sec":1727444501,"ts_usec":298228,"thread":"50170:0x1d6f0dec0","session_name":"txn-recover","category":"WT_VERB_RECOVERY_PROGRESS","category_id":30,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"recovery was completed successfully and took 0ms, including 0ms for the log replay, 0ms for the rollback to stable, and 0ms for the checkpoint."}}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.319+02:00"},"s":"I",  "c":"STORAGE",  "id":4795906, "ctx":"initandlisten","msg":"WiredTiger opened","attr":{"durationMillis":675}}"" +21ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.319+02:00"},"s":"I",  "c":"RECOVERY", "id":23987,   "ctx":"initandlisten","msg":"WiredTiger recoveryTimestamp","attr":{"recoveryTimestamp":{"$timestamp":{"t":0,"i":0}}}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.356+02:00"},"s":"I",  "c":"STORAGE",  "id":20320,   "ctx":"initandlisten","msg":"createCollection","attr":{"namespace":"admin.system.version","uuidDisposition":"provided","uuid":{"uuid":{"$uuid":"73657337-ddf1-4eb4-8eea-17176201fde3"}},"options":{"uuid":{"$uuid":"73657337-ddf1-4eb4-8eea-17176201fde3"}}}}"" +37ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"initandlisten","msg":"Index build: done building","attr":{"buildUUID":null,"collectionUUID":{"uuid":{"$uuid":"73657337-ddf1-4eb4-8eea-17176201fde3"}},"namespace":"admin.system.version","index":"_id_","ident":"index-1--8556849059353303232","collectionIdent":"collection-0--8556849059353303232","commitTimestamp":null}}"" +21ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"REPL",     "id":20459,   "ctx":"initandlisten","msg":"Setting featureCompatibilityVersion","attr":{"newVersion":"7.0"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"REPL",     "id":5853300, "ctx":"initandlisten","msg":"current featureCompatibilityVersion value","attr":{"featureCompatibilityVersion":"7.0","context":"setFCV"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"NETWORK",  "id":4915702, "ctx":"initandlisten","msg":"Updated wire specification","attr":{"oldSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":21},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":21},"outgoing":{"minWireVersion":6,"maxWireVersion":21},"isInternalClient":true},"newSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":21},"incomingInternalClient":{"minWireVersion":21,"maxWireVersion":21},"outgoing":{"minWireVersion":21,"maxWireVersion":21},"isInternalClient":true}}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"NETWORK",  "id":4915702, "ctx":"initandlisten","msg":"Updated wire specification","attr":{"oldSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":21},"incomingInternalClient":{"minWireVersion":21,"maxWireVersion":21},"outgoing":{"minWireVersion":21,"maxWireVersion":21},"isInternalClient":true},"newSpec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":21},"incomingInternalClient":{"minWireVersion":21,"maxWireVersion":21},"outgoing":{"minWireVersion":21,"maxWireVersion":21},"isInternalClient":true}}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"REPL",     "id":5853300, "ctx":"initandlisten","msg":"current featureCompatibilityVersion value","attr":{"featureCompatibilityVersion":"7.0","context":"startup"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"STORAGE",  "id":5071100, "ctx":"initandlisten","msg":"Clearing temp directory"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"CONTROL",  "id":6608200, "ctx":"initandlisten","msg":"Initializing cluster server parameters from disk"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"CONTROL",  "id":20536,   "ctx":"initandlisten","msg":"Flow Control is enabled on this deployment"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.377+02:00"},"s":"I",  "c":"FTDC",     "id":20625,   "ctx":"initandlisten","msg":"Initializing full-time diagnostic data capture","attr":{"dataDirectory":"/var/folders/pg/t48q3kmx7l1_2_t4nzfd7zf80000gn/T/mongo-mem-TpDc3wXVWxc8/diagnostic.data"}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.378+02:00"},"s":"I",  "c":"STORAGE",  "id":20320,   "ctx":"initandlisten","msg":"createCollection","attr":{"namespace":"local.startup_log","uuidDisposition":"generated","uuid":{"uuid":{"$uuid":"ab519d2e-3fe9-4d21-acd9-1bb183e50123"}},"options":{"capped":true,"size":10485760}}}"" +1ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"initandlisten","msg":"Index build: done building","attr":{"buildUUID":null,"collectionUUID":{"uuid":{"$uuid":"ab519d2e-3fe9-4d21-acd9-1bb183e50123"}},"namespace":"local.startup_log","index":"_id_","ident":"index-3--8556849059353303232","collectionIdent":"collection-2--8556849059353303232","commitTimestamp":null}}"" +20ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"REPL",     "id":6015317, "ctx":"initandlisten","msg":"Setting new configuration state","attr":{"newState":"ConfigReplicationDisabled","oldState":"ConfigPreStart"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"STORAGE",  "id":22262,   "ctx":"initandlisten","msg":"Timestamp monitor starting"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"NETWORK",  "id":23015,   "ctx":"listener","msg":"Listening on","attr":{"address":"/tmp/mongodb-61168.sock"}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"NETWORK",  "id":23015,   "ctx":"listener","msg":"Listening on","attr":{"address":"<IP_ADDRESS>"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"NETWORK",  "id":23016,   "ctx":"listener","msg":"Waiting for connections","attr":{"port":61168,"ssl":"off"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"CONTROL",  "id":8423403, "ctx":"initandlisten","msg":"mongod startup complete","attr":{"Summary of time elapsed":{"Startup from clean shutdown?":true,"Statistics":{"Transport layer setup":"1 ms","Run initial syncer crash recovery":"0 ms","Create storage engine lock file in the data directory":"0 ms","Get metadata describing storage engine":"0 ms","Create storage engine":"711 ms","Write current PID to file":"0 ms","Write a new metadata for storage engine":"0 ms","Initialize FCV before rebuilding indexes":"0 ms","Drop abandoned idents and get back indexes that need to be rebuilt or builds that need to be restarted":"0 ms","Rebuild indexes for collections":"0 ms","Load cluster parameters from disk for a standalone":"0 ms","Build user and roles graph":"0 ms","Set up the background thread pool responsible for waiting for opTimes to be majority committed":"0 ms","Initialize information needed to make a mongod instance shard aware":"0 ms","Start up the replication coordinator":"0 ms","Start transport layer":"0 ms","_initAndListen total elapsed time":"755 ms"}}}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"STORAGE",  "id":20320,   "ctx":"LogicalSessionCacheRefresh","msg":"createCollection","attr":{"namespace":"config.system.sessions","uuidDisposition":"generated","uuid":{"uuid":{"$uuid":"15eb7558-b015-4d9c-869e-7cd77279e8e9"}},"options":{}}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: constructor: Instance is ready! +0ms
  MongoMS:MongoInstance Mongo[61168]: start: Processes Started +1ms
  MongoMS:MongoMemoryServer Mongo[61168]: _startUpInstance: Instance Started, createAuth: "false" +870ms
  MongoMS:MongoMemoryServer Mongo[61168]: start: Instance fully Started +0ms
  MongoMS:MongoMemoryServer Mongo[61168]: stop: Called .stop() method +0ms
  MongoMS:MongoMemoryServer Mongo[61168]: stop: Stopping MongoDB server on port 61168 with pid 50170 +0ms
  MongoMS:MongoInstance Mongo[61168]: stop +0ms
  MongoMS:utils Mongo[61168] killProcess: mongodProcess: sending "SIGINT" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.398+02:00"},"s":"I",  "c":"CONTROL",  "id":20712,   "ctx":"LogicalSessionCacheReap","msg":"Sessions collection is not set up; waiting until next sessions reap interval","attr":{"error":"NamespaceNotFound: config.system.sessions does not exist"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.399+02:00"},"s":"I",  "c":"CONTROL",  "id":23377,   "ctx":"SignalHandler","msg":"Received signal","attr":{"signal":2,"error":"Interrupt: 2"}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.399+02:00"},"s":"I",  "c":"CONTROL",  "id":23381,   "ctx":"SignalHandler","msg":"will terminate after current cmd ends"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.399+02:00"},"s":"I",  "c":"REPL",     "id":4784900, "ctx":"SignalHandler","msg":"Stepping down the ReplicationCoordinator for shutdown","attr":{"waitTimeMillis":15000}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.399+02:00"},"s":"I",  "c":"REPL",     "id":4794602, "ctx":"SignalHandler","msg":"Attempting to enter quiesce mode"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.399+02:00"},"s":"I",  "c":"-",        "id":6371601, "ctx":"SignalHandler","msg":"Shutting down the FLE Crud thread pool"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.399+02:00"},"s":"I",  "c":"COMMAND",  "id":4784901, "ctx":"SignalHandler","msg":"Shutting down the MirrorMaestro"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.399+02:00"},"s":"I",  "c":"SHARDING", "id":4784902, "ctx":"SignalHandler","msg":"Shutting down the WaitForMajorityService"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.400+02:00"},"s":"I",  "c":"CONTROL",  "id":4784903, "ctx":"SignalHandler","msg":"Shutting down the LogicalSessionCache"}"" +1ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.420+02:00"},"s":"I",  "c":"REPL",     "id":7360102, "ctx":"LogicalSessionCacheRefresh","msg":"Added oplog entry for create to transaction","attr":{"namespace":"config.$cmd","uuid":{"uuid":{"$uuid":"15eb7558-b015-4d9c-869e-7cd77279e8e9"}},"object":{"create":"system.sessions","idIndex":{"v":2,"key":{"_id":1},"name":"_id_"}}}}"" +20ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.420+02:00"},"s":"I",  "c":"REPL",     "id":7360100, "ctx":"LogicalSessionCacheRefresh","msg":"Added oplog entry for createIndexes to transaction","attr":{"namespace":"config.$cmd","uuid":{"uuid":{"$uuid":"15eb7558-b015-4d9c-869e-7cd77279e8e9"}},"object":{"createIndexes":"system.sessions","v":2,"key":{"lastUse":1},"name":"lsidTTLIndex","expireAfterSeconds":1800}}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.430+02:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"LogicalSessionCacheRefresh","msg":"Index build: done building","attr":{"buildUUID":null,"collectionUUID":{"uuid":{"$uuid":"15eb7558-b015-4d9c-869e-7cd77279e8e9"}},"namespace":"config.system.sessions","index":"_id_","ident":"index-5--8556849059353303232","collectionIdent":"collection-4--8556849059353303232","commitTimestamp":null}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.430+02:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"LogicalSessionCacheRefresh","msg":"Index build: done building","attr":{"buildUUID":null,"collectionUUID":{"uuid":{"$uuid":"15eb7558-b015-4d9c-869e-7cd77279e8e9"}},"namespace":"config.system.sessions","index":"lsidTTLIndex","ident":"index-6--8556849059353303232","collectionIdent":"collection-4--8556849059353303232","commitTimestamp":null}}"" +10ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"NETWORK",  "id":20562,   "ctx":"SignalHandler","msg":"Shutdown: going to close listening sockets"}"" +1ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"NETWORK",  "id":23017,   "ctx":"listener","msg":"removing socket file","attr":{"path":"/tmp/mongodb-61168.sock"}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"NETWORK",  "id":4784905, "ctx":"SignalHandler","msg":"Shutting down the global connection pool"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"CONTROL",  "id":4784906, "ctx":"SignalHandler","msg":"Shutting down the FlowControlTicketholder"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"-",        "id":20520,   "ctx":"SignalHandler","msg":"Stopping further Flow Control ticket acquisitions."}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"CONTROL",  "id":4784908, "ctx":"SignalHandler","msg":"Shutting down the PeriodicThreadToAbortExpiredTransactions"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"REPL",     "id":4784909, "ctx":"SignalHandler","msg":"Shutting down the ReplicationCoordinator"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"SHARDING", "id":4784910, "ctx":"SignalHandler","msg":"Shutting down the ShardingInitializationMongoD"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"REPL",     "id":4784911, "ctx":"SignalHandler","msg":"Enqueuing the ReplicationStateTransitionLock for shutdown"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"-",        "id":4784912, "ctx":"SignalHandler","msg":"Killing all operations for shutdown"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"-",        "id":4695300, "ctx":"SignalHandler","msg":"Interrupted all currently running operations","attr":{"opsKilled":3}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"TENANT_M", "id":5093807, "ctx":"SignalHandler","msg":"Shutting down all TenantMigrationAccessBlockers on global shutdown"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"ASIO",     "id":22582,   "ctx":"TenantMigrationBlockerNet","msg":"Killing all outstanding egress activity."}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"ASIO",     "id":6529201, "ctx":"SignalHandler","msg":"Network interface redundant shutdown","attr":{"state":"Stopped"}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"ASIO",     "id":22582,   "ctx":"SignalHandler","msg":"Killing all outstanding egress activity."}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"COMMAND",  "id":4784913, "ctx":"SignalHandler","msg":"Shutting down all open transactions"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"REPL",     "id":4784914, "ctx":"SignalHandler","msg":"Acquiring the ReplicationStateTransitionLock for shutdown"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"INDEX",    "id":4784915, "ctx":"SignalHandler","msg":"Shutting down the IndexBuildsCoordinator"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"NETWORK",  "id":4784918, "ctx":"SignalHandler","msg":"Shutting down the ReplicaSetMonitor"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"SHARDING", "id":4784921, "ctx":"SignalHandler","msg":"Shutting down the MigrationUtilExecutor"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"ASIO",     "id":22582,   "ctx":"MigrationUtil-TaskExecutor","msg":"Killing all outstanding egress activity."}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"COMMAND",  "id":4784923, "ctx":"SignalHandler","msg":"Shutting down the ServiceEntryPoint"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"CONTROL",  "id":4784927, "ctx":"SignalHandler","msg":"Shutting down the HealthLog"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"CONTROL",  "id":4784928, "ctx":"SignalHandler","msg":"Shutting down the TTL monitor"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"INDEX",    "id":3684100, "ctx":"SignalHandler","msg":"Shutting down TTL collection monitor thread"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"INDEX",    "id":3684101, "ctx":"SignalHandler","msg":"Finished shutting down TTL collection monitor thread"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"CONTROL",  "id":6278511, "ctx":"SignalHandler","msg":"Shutting down the Change Stream Expired Pre-images Remover"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"CONTROL",  "id":4784929, "ctx":"SignalHandler","msg":"Acquiring the global lock for shutdown"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"CONTROL",  "id":4784930, "ctx":"SignalHandler","msg":"Shutting down the storage engine"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":22320,   "ctx":"SignalHandler","msg":"Shutting down journal flusher thread"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":22321,   "ctx":"SignalHandler","msg":"Finished shutting down journal flusher thread"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":22322,   "ctx":"SignalHandler","msg":"Shutting down checkpoint thread"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":22323,   "ctx":"SignalHandler","msg":"Finished shutting down checkpoint thread"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":22261,   "ctx":"SignalHandler","msg":"Timestamp monitor shutting down"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":20282,   "ctx":"SignalHandler","msg":"Deregistering all the collections"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":22317,   "ctx":"SignalHandler","msg":"WiredTigerKVEngine shutting down"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":22318,   "ctx":"SignalHandler","msg":"Shutting down session sweeper thread"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.431+02:00"},"s":"I",  "c":"STORAGE",  "id":22319,   "ctx":"SignalHandler","msg":"Finished shutting down session sweeper thread"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.436+02:00"},"s":"I",  "c":"STORAGE",  "id":4795902, "ctx":"SignalHandler","msg":"Closing WiredTiger","attr":{"closeConfig":"leak_memory=true,use_timestamp=false,"}}"" +5ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.437+02:00"},"s":"I",  "c":"WTCHKPT",  "id":22430,   "ctx":"SignalHandler","msg":"WiredTiger message","attr":{"message":{"ts_sec":1727444501,"ts_usec":437405,"thread":"50170:0x16d0bf000","session_name":"close_ckpt","category":"WT_VERB_CHECKPOINT_PROGRESS","category_id":6,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"saving checkpoint snapshot min: 34, snapshot max: 34 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 1"}}}"" +1ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.508+02:00"},"s":"I",  "c":"WTRECOV",  "id":22430,   "ctx":"SignalHandler","msg":"WiredTiger message","attr":{"message":{"ts_sec":1727444501,"ts_usec":508584,"thread":"50170:0x16d0bf000","session_name":"WT_CONNECTION.close","category":"WT_VERB_RECOVERY_PROGRESS","category_id":30,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"shutdown checkpoint has successfully finished and ran for 71 milliseconds"}}}"" +71ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.508+02:00"},"s":"I",  "c":"WTRECOV",  "id":22430,   "ctx":"SignalHandler","msg":"WiredTiger message","attr":{"message":{"ts_sec":1727444501,"ts_usec":508688,"thread":"50170:0x16d0bf000","session_name":"WT_CONNECTION.close","category":"WT_VERB_RECOVERY_PROGRESS","category_id":30,"verbose_level":"DEBUG_1","verbose_level_id":1,"msg":"shutdown was completed successfully and took 72ms, including 0ms for the rollback to stable, and 71ms for the checkpoint."}}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.542+02:00"},"s":"I",  "c":"STORAGE",  "id":4795901, "ctx":"SignalHandler","msg":"WiredTiger closed","attr":{"durationMillis":106}}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.542+02:00"},"s":"I",  "c":"STORAGE",  "id":22279,   "ctx":"SignalHandler","msg":"shutdown: removing fs lock..."}"" +34ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.542+02:00"},"s":"I",  "c":"-",        "id":4784931, "ctx":"SignalHandler","msg":"Dropping the scope cache for shutdown"}
  MongoMS:MongoInstance {"t":{"$date":"2024-09-27T15:41:41.542+02:00"},"s":"I",  "c":"FTDC",     "id":20626,   "ctx":"SignalHandler","msg":"Shutting down full-time diagnostic data capture"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.542+02:00"},"s":"I",  "c":"CONTROL",  "id":20565,   "ctx":"SignalHandler","msg":"Now exiting"}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.542+02:00"},"s":"I",  "c":"CONTROL",  "id":8423404, "ctx":"SignalHandler","msg":"mongod shutdown complete","attr":{"Summary of time elapsed":{"Statistics":{"Enter terminal shutdown":"0 ms","Step down the replication coordinator for shutdown":"0 ms","Time spent in quiesce mode":"0 ms","Shut down FLE Crud subsystem":"0 ms","Shut down MirrorMaestro":"0 ms","Shut down WaitForMajorityService":"0 ms","Shut down the logical session cache":"31 ms","Shut down the transport layer":"1 ms","Shut down the global connection pool":"0 ms","Shut down the flow control ticket holder":"0 ms","Kill all operations for shutdown":"0 ms","Shut down all tenant migration access blockers on global shutdown":"0 ms","Shut down all open transactions":"0 ms","Acquire the RSTL for shutdown":"0 ms","Shut down the IndexBuildsCoordinator and wait for index builds to finish":"0 ms","Shut down the replica set monitor":"0 ms","Shut down the migration util executor":"0 ms","Shut down the health log":"0 ms","Shut down the TTL monitor":"0 ms","Shut down expired pre-images and documents removers":"0 ms","Shut down the storage engine":"111 ms","Wait for the oplog cap maintainer thread to stop":"0 ms","Shut down full-time data capture":"0 ms","shutdownTask total elapsed time":"143 ms"}}}}"" +0ms
  MongoMS:MongoInstance Mongo[61168]: stdoutHandler: ""{"t":{"$date":"2024-09-27T15:41:41.542+02:00"},"s":"I",  "c":"CONTROL",  "id":23138,   "ctx":"SignalHandler","msg":"Shutting down","attr":{"exitCode":0}}"" +0ms
  MongoMS:utils Mongo[61168] killProcess: mongodProcess: got exit signal, Code: 0, Signal: null +145ms
  MongoMS:MongoInstance Mongo[61168]: closeHandler: code: "0", signal: "null" +2ms
  MongoMS:utils Mongo[61168] killProcess: killerProcess: sending "SIGINT" +0ms
  MongoMS:utils Mongo[61168] killProcess: killerProcess: got exit signal, Code: 0, Signal: null +2ms
  MongoMS:MongoInstance Mongo[61168]: stop: Instance Finished Shutdown +2ms
  MongoMS:MongoMemoryServer Mongo[61168]: cleanup: { doCleanup: true, force: false } +148ms
  MongoMS:MongoMemoryServer Mongo[61168]: cleanup: removing tmpDir at /var/folders/pg/t48q3kmx7l1_2_t4nzfd7zf80000gn/T/mongo-mem-TpDc3wXVWxc8 +0ms

Do you know why it happenes?
Nope - I haven't digged through the source though. My initial thought was that something previously cached in the startup procedure pre-v10, isn't anymore.

because you are using MMS 10.x and the default binary of 7.0.x (currently 7.0.11 in 10.0.x), you are using (default) storage engine wiredTiger(disk based) instead of the previous ephemeralForTest(mostly ram based) because mongodb 7.0 removed that storage engine. there is another ram storage engine available, but only for business mongodb (which this package does not use).
the workarounds are:

work with the new storage engine and set your database path (by default the temporary storage of your OS, in your case it is /var/folders/pg/t48q3kmx7l1_2_t4nzfd7zf80000gn/T/ according to the provided logs) to a tmpfs or equivalent, if possible
explicitly set the mongodb version to use to 6.x or earlier (via config option VERSION))

Note that there has been a note in the Migrate to version 10.0.0 guide.

thanks @hasezoey !
I did see the note but overlooked the down-the-line impact of that binary upgrade.
I'll probably stick to v6 for now because I'm not sure yet how to setup an in-memory storage consistent across dev OS and CI vms.

If it helps here how we configured ramdisk for both mac and circleci:
Mac

scripts/mkramdisk.sh

#!/bin/sh

# https://superuser.com/questions/456803/create-ram-disk-mount-to-specific-folder-in-osx

ramfs_size_mb=2048
mount_point=/tmp/rdisk

ramfs_size_sectors=$((${ramfs_size_mb}*1024*1024/512))
ramdisk_dev=`hdid -nomount ram://${ramfs_size_sectors}`

newfs_hfs -v 'ram disk' ${ramdisk_dev}
mkdir -p ${mount_point}
mount -o noatime -t hfs ${ramdisk_dev} ${mount_point}

echo "remove with:"
echo "umount ${mount_point}"
echo "diskutil eject ${ramdisk_dev}"

Run this script before running tests
CircleCI
/mnt/ramdisk is available, see https://circleci.com/docs/using-docker/#ram-disks
create MongoMemoryServer
get tmpdir:

const baseTmpdir = (() => {
  if (platform === "darwin") {
    const rdiskPath = "/tmp/rdisk";
    if (!fsSync.existsSync(rdiskPath)) {
      throw new Error(
        rdiskPath + " does not exist. Execute script mkramdisk.sh first."
      );
    }
    return rdiskPath;
  }

  if (process.env.CI) {
    const rdiskPath = "/mnt/ramdisk";

    if (!fsSync.existsSync(rdiskPath)) {
      throw new Error(
        rdiskPath +
          " does not exist. Check circle doc: https://circleci.com/docs/using-docker/#ram-disks."
      );
    }
    return rdiskPath;
  }

  console.warn(
    'It seems you are not on a "darwin" platform or CI environment, falling back to tmp directory. Tests might be slower that expected.'
  );

  return tmpdir();
})();

        const dbPath = path.join(baseTmpdir, `${i}`);
        await fs.mkdir(dbPath, { recursive: true });
        return MongoMemoryServer.create({
          instance: {
            port: 5100 + i,
            dbPath,
          },
          binary: {
            version: "7.0.12",
          },
      });


Cannot install rate-limit-redis 3.1.0 with express-rate-limit 7.0.0

Description
I've installed latest version (7.0.0) of express-rate-limit and wanted to add Redis store. However, when I tried  to install latest rate-limit-redis I got following error:
npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/express-rate-limit
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer express-rate-limit@"^6" from<EMAIL_ADDRESS>npm ERR! node_modules/rate-limit-redis
npm ERR!   rate-limit-redis@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

Library version
3.1.0
Node version
v18.16.0
Typescript version (if you are using it)
No response
Module system
CommonJS

Hi,
Thanks for reporting the issue.
Could you please use the --legacy-peer-deps flag for now, while I release a version with peerDeps set to >= 6?
Thanks!

That was fast, thanks a lot!


breaking(v2): editUrl should point to website instead of docsDir

Motivation
In v1, editUrl is pointing to docsDir and its always pointing to next for the edit.
Try https://docusaurus.io/docs/en/1.13.0/installation, notice the edit is for next docs only.
This breaking changes makes people moving docs folder around easier.
For example, if I renamed docs folder from docs to document. Before this PR i have to change the docs plugin path options from docs to document AND I HAVE to update my editUrl from https://github.com/facebook/docusaurus/edit/master/website/docs/ to https://github.com/facebook/docusaurus/edit/master/website/document/ as well. Double work.
After this PR, I only need to do it once
It supports versioned_docs and translated_docs editUrl better in future
Since we can always resolve it based from website dir. Since we already have lot of aliasing through @site, it makes more sense to point it to website instead of docsDir.
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan

Updated test passes
Netlify editUrl still works

Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)

I'm also not sure on the best approach. For now I've tried to minimize the damage by editing the docs on migration.

Don't merge since it includes docs change. Will only merge right before release  new alpha


No client appened to this.$apollo

I reproduced the error in this repo: https://github.com/jarnojellesma/graphql-experiment/tree/master/client
nuxt.config:
module.exports = {
  modules: ['@nuxtjs/apollo'],
  apollo: {
    clientConfigs: {
      default: '~/apollo/client-configs/default.js'
    }
  },
  rootDir: path.resolve(__dirname),
  srcDir: path.resolve(__dirname),
};

apollo/client-configs/default:
export default (ctx) => {
  const httpLink = new HttpLink({ uri: 'http://localhost:3030/graphql' })
  console.log('default client');

  console.log(ctx.isServer)

  const middlewareLink = new ApolloLink((operation, forward) => {
    return forward(operation)
  })
  const link = middlewareLink.concat(httpLink)
  return {
    link,
    cache: new InMemoryCache()
  }
};

Now the client is supposed to be accessible on the this.$apollo within component methods. But it is undefined:

This question is available on Nuxt.js community (#c41)

@jarnojellesma please check the 'Usage' section of the docs. Especially the section https://github.com/nuxt-community/apollo-module#query-on-any-component

I have the same issue. It has nothing to do with the "Usage" section. The apollo provider is undefined for some reason on the Vue component.

Same problem here, maybe due to some api changes in vue-apollo? this.$apollo.defaultClient is undefined running inside a method.

@faroutchris @nahue can you check which version of vue-apollo you have installed? If you run on beta then please check out the PR #81

Thanks @dohomi that was it! i have vue-apollo 3.0.0-beta.2.
I've made the changes in the PR locally and it worked perfectly!

Ok great I will publish a release later today

this issue is resolved with v3.0.3

Wow, great! Thanks for the quick response. I was indeed running vue-apollo 3.0.0-beta.2

when i try to add modules: ['@nuxtjs/apollo'], i get this ERROR Cannot start nuxt: [@nuxtjs/apollo] Atleast one client must be configured.  error

same problem
ERROR  Cannot restart nuxt:  [@nuxtjs/apollo] Atleast one client must be configured.


misc,python: Add isort hook to pre-commit

There are a couple of places where isort seems to be mixing modules in the local directory and in gem5 itself. That seems wrong to me. We might want to try to add this to the configuration:
known_first_party = m5

Alternatively, we could do something like this (I think):
known_m5 = m5
known_gem5 = gem5
sections=FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,M5,GEM5,LOCALFOLDER

I can't remember what the style guide says off the top of my head, but it should be something like the above.

Also, I would be fine not including this in the blame ignore file. The change is pretty pretty limited in scope and it won't mess with git blame that much.

There are a couple of places where isort seems to be mixing modules in the local directory and in gem5 itself. That seems wrong to me. We might want to try to add this to the configuration:
known_first_party = m5

Alternatively, we could do something like this (I think):
known_m5 = m5
known_gem5 = gem5
sections=FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,M5,GEM5,LOCALFOLDER

I can't remember what the style guide says off the top of my head, but it should be something like the above.

I've incorporated this. See if it works for you.

There are a couple of places where isort seems to be mixing modules in the local directory and in gem5 itself. That seems wrong to me. We might want to try to add this to the configuration:
known_first_party = m5

Alternatively, we could do something like this (I think):
known_m5 = m5
known_gem5 = gem5
sections=FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,M5,GEM5,LOCALFOLDER

I can't remember what the style guide says off the top of my head, but it should be something like the above.

I've incorporated this. See if it works for you.

There is something weird going on in configs/. It seems like common isn't detected as a local folder for some reason. Not sure what to do about that though. We might need to use relative imports or do something creative here if we want it to be consistent.
Here are some more thoughts:

Do we want to order m5.params and m5.proxy with respect to m5.objects? Most existing files seem to have params and proxy imports before object imports. Treating them as just another m5 thing works for me.
Do we want to put _m5  in its own block? It's very much internal plumbing, so it might make sense, but the current config seems OK as well.
We should probably explicitly tell isort what to do about slicc. Should it be in its own group, m5, or firstparty?

@andysan

Do we want to put _m5 in its own block? It's very much internal plumbing, so it might make sense, but the current config seems OK as well.

I made this change. Please take a look to see if that is what you had in mind.

We should probably explicitly tell isort what to do about slicc. Should it be in its own group, m5, or first-party?

Do you have a suggestion for which solution would be the best?

@andysan

Do we want to put _m5 in its own block? It's very much internal plumbing, so it might make sense, but the current config seems OK as well.

I made this change. Please take a look to see if that is what you had in mind.

This is exactly what I had in mind, thanks! I think this makes sense.

We should probably explicitly tell isort what to do about slicc. Should it be in its own group, m5, or first-party?

Do you have a suggestion for which solution would be the best?

Maybe we should just treat slicc as if it belongs to _m5? It might even make sense to move it into that namespace at some if it isn't used by external scripts.

This PR has been sitting around for a while without much input from anyone other than Bobby and Ivana. I'm going to go ahead and merge this since I think it is good enough and we'll likely end up with annoying conflicts if we wait.


Docker pre.entrypoint links to Node pre.pre-if

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#runspre-entrypoint
What part(s) of the article would you like to see updated?
I think a distinct .pre-if should be added to the https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#runs-for-docker-container-actions and https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#runspre-entrypoint's runs.pre-if link should be changed to point to it.
Additional information
Here's a run with pre-if: true:
  pre-entrypoint: '/pre.sh'
  pre-if: true

pre

Here's a run with pre-if: false (which is good because the pre-entrypoint was broken):
  pre-entrypoint: 'pre.sh'
  pre-if: false

https://github.com/check-spelling-sandbox/bookish-rotary-phone/actions/runs/11798769996/job/32865715637

I'm not sure how easy it would be to split the two pre-if statements two get distinct anchors. Offhand, I'd strongly recommend splitting the document into:

page for actions in general that links to individual pages for javascript, composite, and docker
reusable shared-action-definitions head basically everything from https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#about-yaml-syntax-for-github-actions stopping before runs
page for JavaScript actions with includes for reusable shared-action-definitions head and reusable shared-action-definitions tail
page for composite actions with includes for reusable shared-action-definitions head and reusable shared-action-definitions tail
page for Docker container actions with includes for reusable shared-action-definitions head and reusable shared-action-definitions tail
reusable shared-action-definitions tail with branding

The number of people who want to look at the syntax for more than one kind of action at a time can be counted on one hand and they all more or less work on either actions/runner or nektos/act. Everyone else only cares about one kind of action (on average javascript or composite) and doesn't need to be confused by the other two.

@jsoref Thank you for raising this issue! I'll get this triaged for review :sparkles: Our team will provide feedback regarding the best next steps for this issue - thanks for your patience! 💛

@jsoref Thanks for your patience while our SME team reviewed! ✨ They agreed on almost suggestions, but wanted to relay the following -

The only thing is that I don't think that a new section like this should just link to the run.pre-if section for Javascript, because of the disparity between pre vs pre-entrypoint.

We wanted to get your thoughts on this before opening this up for contributions, just so we're all on the same page 💛

I'm happy with totally different content sections or reusable content blocks. I can't remember precisely what I was thinking here and the GitHub Mobile app UI is not helping me figure it out.
As long as it's possible to easily understand the two at least somewhat unrelated items, I'd be happy.
(I don't expect to be able to look back/into anything until late December or early January.)

I'm happy with totally different content sections or reusable content blocks. I can't remember precisely what I was thinking here and the GitHub Mobile app UI is not helping me figure it out.
As long as it's possible to easily understand the two at least somewhat unrelated items, I'd be happy.

@jsoref Awesome! We're aligned on this ✨

(I don't expect to be able to look back/into anything until late December or early January.)

No problem - we are happy to let this issue rest until you are ready to submit a PR if this sounds good to you 💛

Feel free to update the guidance and I'll try to circle back when I can.


.scala in directory breaks compilation

steps
create a project with a package folder ending with .scala such as src/main/scala/ch.epfl.scala
webapp
├── js
│   └── src
│       └── main
│           └── scala
│               └── ch.epfl.scala
│                   └── Client.scala
├── jvm
│   └── src
│       └── main
│           └── scala
│               └── ch.epfl.scala
│                   └── Server.scala
└── shared
    └── src
        └── main
            └── scala
                └── ch.epfl.scala
                    └── Api.scala

problem
when compiling:
[error] source file '/home/gui/fluffy-broccoli/webapp/js/src/main/scala/ch.epfl.scala' could not be found
[error] one error found
[error] source file '/home/gui/fluffy-broccoli/webapp/jvm/src/main/scala/ch.epfl.scala' could not be found
[error] one error found

expectation
I should be able to use .scala in the directory structure

Does it make sense to name the directory ch.epfl.scala instead of ch/epfl/scala?

yep that would be a workaround. I like the a.b.c syntax it faster to navigate.

A workaround for sbt 0.13.x:
// build.sbt
includeFilter in unmanagedSources := (includeFilter in unmanagedSources).value && new SimpleFileFilter(_.isFile)

or
// project/plugins.sbt
addSbtPlugin("com.thoughtworks.sbt-best-practice" % "issue2552" % "latest.release")


One-line snippet

I don't have a screenshot, but I got a one-line snippet and could only get +10 points even if I knew the answer
(it was powershell)

Hi, thanks for opening an issue! Did the point counter start at 10, or did it go from 100 to 10 when the line was shown? Also, what version did you use?

it was only 1 line, no empty lines, i used the latest version v1.0.20 and it went directly to 10


fix md5 etag mismatch on response

I think there are a couple of options here.

Simplest is to drop the etag header from the response.

Generate a new etag that is derived from the object etag and something about grok. eg Etag: "-". This will likely still cause an error in the swift CLI tool, but it gives clients that know about grok a better chance to use conditional requests with grok

so sorry. I put this on the wrong repo


Unable to create upscale simple workflow with selectable ESRGAN model input

I'm trying to make a simple workflow that lets me select an ESRGAN model to upscale an image but from what I can tell there doesn't seem to be a way to select an upscale model using a SwarmInput node. Neither the SwarmInputModelName node nor the SwarmInputDropdown node will connect to the Load Upscale Model node even though they both output COMBO act like they will connect (the model_name input on the Load Upscale Model node highlights when dragging a COMBO output to it but it doesn't connect.)
It may not be a glitch but maybe an oversight. It seems that the SwarmInputModelName node does not have ESRGAN models as a subtype so that may be why it won't connect to the Load Upscale Model node. I tried to use the SwarmInputDropdown node as a workaround by manually listing the models I wanted to use but that doesn't seem to work either.
Here's just an example of a very simple workflow that I feel should work but doesn't (either with the SwarmInputModelName or the SwarmInputDropdown nodes)

You've already done a bunch of work at my request so I understand if you decide to draw the line here. I think though this would be good for a lot of people who would like to replicate, say, the Extras tab from A1111 for just doing a simple ESRGAN upscale. Thank you for everything :)

Technically Dropdown is the correct the thing to use, it's just very jank due to comfy litegraph limits with getting COMBO inputs to connect together -- you can drag backwards from the model_name input, and drop a reroute, then backwards from that to the output the SwarmInput node.
Yes this is extremely cursed, but it's the only way to make litegraph let you do it atm.
The other issue is you have to manually specify the combo values -- I fixed it so you can simply empty the values input and it will automatically load the values correct from the node
The other other issue is at some point comfy upstream broke that working with prompt validation... I pushed a commit that... uh... gently bypasses it. Read the commit details at your own risk.
But yeah with the above changes applied, test workflow works as intended

It works :) you're as awesome as ever! It's janky but with it under a simple workflow I'm not going to care lol thank you again!

I was given a much better way to do (empty output type), which now lets you connect directly from the dropdown's output to the input box without the wrangling


Fix python uninstrumented

I was attempting to follow this quick start recently and ran into a few issues. Currently this sample app throws an error, and won't report any otel monitoring.
This PR fixes the broken app, cleans up the readme and adds instructions for how to get monitoring to actually be sent via the auto instrumentation. The getting started guide here implies that we shouldn't need to add code to get the traces and metrics monitoring generated, but that was not my experience (couldn't get anything but logs to console without adding the FlaskInstrumentor().instrument_app(app) line)
Also note that there is some overlapping instructions for this tutorial on the New Relic docs site here, and it is probably worth maintaining a single copy of these instructions and providing a link in one way or another. (I have settled for now for just getting things into a working state here)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Amy Boyle seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

This example has evolved considerably since this PR. Not sure if the same problems still exist, but if they do a new PR is justified. Closing.


Go: mismatch between json struct tags

What version of protobuf and what language are you using?
Version: acaef6a  (can be seen in the testprotos on master)
What did you do?
Generated proto files, used the grpc-gateway package which exposed a mismatch in the json fields.
However, the exact steps are not that relevant I believe since they can be seen in the testprotos in this repository, here for example (but if useful I could make a small example too).
What did you expect to see?
Either (I'm not sure what the official spec is):
OptionalInt32          int32                             `protobuf:"varint,1,opt,name=optional_int32,json=optionalInt32,proto3" json:"optionalInt32,omitempty"`

or:
OptionalInt32          int32                             `protobuf:"varint,1,opt,name=optional_int32,json=optional_int32,proto3" json:"optional_int32,omitempty"`

This is a problem because some code (grpc-gateway for example) uses the protobuf annotation field but the golang json package uses the json annotation.
What did you see instead?
The tags regarding json in on the fields of the generated structs do not match:
	OptionalInt32          int32                             `protobuf:"varint,1,opt,name=optional_int32,json=optionalInt32,proto3" json:"optional_int32,omitempty"`

(Can be seen here)
Anything else we should know about your project / environment?
It can be seen in this repo :)
I raised this in grpc-go where I got pointed to this repository.
My apologies if I misunderstood and this is not the correct place to report this (suspected) issue (of if this is intended behaviour).

This has already been extensively discussed, and we cannot “fix” this without breaking other people’s code. See: Hyrum’s Law
Just one of the many issues that have been opened before: #1307

Thanks for the quick reply, I missed the other issue in my quick search. Too bad that it cannot be changed/fixed easily. A bit disappointing to be honest, on one hand I understand (and respect) that great effort is put in not breaking anything for users relying on current behaviour, on the other hand there are the disclaimers in the readme regarding unspecified behaviour and bugs.
The thing that is not really clear to me is why it would not be make a configurable option where the default value does not change any behaviour?

There is a “configurable option”: use protojson which correctly implements the the proto3→JSON mapping
Why not have a configurable option to fix the json tag itself? Because the json tag was a mistake. It was added in, because it seemed like it would be so easy to just add it, and viola. But then when a defined JSON mapping was defined, there was no way to compatibly and properly do the JSON mapping with the built in encoding/json, and so 🤦♀ 😭
This is also why the project is now hesitant to implement any “neat and easy expansion” that occasionally comes along. Sometimes, the idea is a cool idea, and it would be really neat to have… and then we think back on how we painted ourselves into a corner implementing JSON mapping early.

Makes sense, thanks for your time!


Contribution: Success

Hi!
The name of this icon is "success". It's a checkmark inside of a circle. It's going to represent when an action/event is successful. The following .zip file has the svg and an image of it in use.
success.zip

Seems like this already exists as icon--checkmark--outline
http://carbondesignsystem.com/style/iconography/library

Hi,
Oh, alright- thanks!


ES6 babel browser compatibility tests

As part of https://github.com/phetsims/chipper/issues/551, I'd love testing of https://phet-dev.colorado.edu/html/wilder/1.0.0-es6.1/phet/wilder_en_phet.html on our main supported platforms.
It is a "pass" if the sim loads normally, and a "failure" if it gets stuck on the loading screen (presumably errored out in the console).
If it fails, I'd love to get console/debugger information from the browser's dev tools if possible.

[x] latest browsers on latest macOS
[x] latest browsers on Windows 10 (esp. IE)
[x] latest browsers on Windows 8 (esp. IE)
[x] latest browsers on Windows 7 (esp. IE)
[x] latest Chrome on Chrome OS
[x] latest Chrome on Android
[x] latest browsers on older macOS
[x] Safari on all versions of iOS

On macOS 10.12 + Safari 10.0, I get the following error:
[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (wilder_en_phet.html, line 0)

The error in https://github.com/phetsims/QA/issues/139#issuecomment-403985195 seems like the wrong URL was typed in (pasted twice).  Can you double check it?

Well, it wouldn't be a normal week if I didn't do something completely embarrassing.
Thanks, @samreid!
The link works fine on macOS 10.12 + Safari 10.0.

QA is finished with this spot check.


Incorrect Link to how to guide to Enable CMK

I believe that while ADX stores data in Azure Storage which is encrypted at rest by default using Microsoft managed keys, enabling ADX to use a CMK to encrypt data stored in the Azure Storage is actually managed via ADX rather than via the Azure Storage (which is hidden to customer).
Therefore this link to "Use your own customer-managed key" actually makes no sense in the context of ADX as it is currently pointing to the Azure Storage documentation on how to enable CMK. It probably should be pointing to this ADX specific CMK page instead: https://docs.microsoft.com/en-us/azure/data-explorer/customer-managed-keys-portal

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: cf4f16b8-0084-0e9e-bf4a-a4aa6ff1ea20
Version Independent ID: 8229462a-5b32-4a72-eb90-7b7f4b4c867f
Content: Secure your cluster with encryption in Azure Data Explorer
Content Source: data-explorer/cluster-encryption-overview.md
Service: data-explorer
GitHub Login: @shsagir
Microsoft Alias: shsagir

@pnarsi Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

Link updated in PR referenced above

#please-close


Adaptation plan for Ensemble

This is an issue to adapt the plan for Ensemble:

[ ] Double check the issues within the ensemble/handler/symuvia/folder
[x] Migrate content to → symupy/api

[x] Update unit tests

[x] Perform testing on new structure
[x] Create a tutorial to use this new structure
[ ] Publish package to pypi

This is the current status:

Added

[ ] tests/test_loadlibrary
[ ] tests/test_api
[ ] tests/test_constants
[ ] tests/test_simulationmocks

For tutorials check c57dfae


Update code and dependencies to be compatible with pulumi 2.0

Hey! I was debugging an issue here where the deployment was hanging at pulumi up which led me to update the packages and some small code changes to be compatible with Pulumi 2.0.

Thank you for the PR @komalali. I will take a look and get back to you.


Delete old scenario data from DB

There is no way to remove or update a scenario once it is added to the DB

Added in v0.0.14


ciphers/signatures: Reject update if module isn't operational

When a FIPS self-test such as for example a pair-wise consistency test fails, the module should go into an error state and refuse any further cryptographic operations.
This is not the case for the RSA or ECDSA pair-wise consistency test, after which EVP_DigestUpdate() and EVP_EncryptUpdate() can still be called.
Add invocations of ossl_prov_is_running() to provider functions called by EVP_DigestUpdate() and EVP_EncryptUpdate() to fix this.
I am aware that new contexts cannot be created, and existing contexts cannot be finalized because the init and final variants of those APIs have the ossl_is_prov_running() call, but our lab claims that is not sufficient, and the update API must also not work on PCT failure.
We added an abort() downstream for these cases, since it's really a corner case that essentially never happens outside of bit-flips, but that's clearly not appropriate upstream, and neither is it a clean solution. In order to reduce our downstream patches, I'm proposing this instead.

For DigestUpdate there is no consequence of this check missing as there is no output generated until DigestFinal() is called. So it is doubtful whether this is really mandated by the FIPS 140 standard. On the other hand CipherUpdate produces an output so this seems like a bug to me.

For DigestUpdate there is no consequence of this check missing as there is no output generated until DigestFinal() is called. So it is doubtful whether this is really mandated by the FIPS 140 standard.

That was also what we argued, but considering that a hashing operation may be triggered in DigestUpdate(), our lab did not accept this explanation.

Your lab is mistaken.  If they are not willing to be reasonable, request a formal CMVP response about this and present your argument there.
Our 140-2 validation passed with things are they are.  We've heard of no issues with this in KeyPair's 140-3 validation (upon which ours is based).
I strongly oppose this change, it introduces what could potentially be a performance regression.  The updates were deliberately and intentionally excluded from the running checks because of this.

Thanks for the review, I'll go back to them and see what we can do.

Closing since this is marked as resolved.

We actually haven't heard back from NIST on this. I'll make sure to ask for a status update in our next meeting with our lab.
They wouldn't let us submit without a change to address this concern, so we're still very much interested in a resolution where we don't have to carry downstream patches.
I'll come back with more info when I have it.


macOS - Open app and sync current timer

Hi, I have and issue.
Imagine I started a timer in the macOS app, and i close the app.
When I open the app again, the timer isn't counting, but in the web it is.
Is this a sync issue?
Thanks

Actually it's working in the last version 7.4.11.
Thanks 👍


🐛 Syncer: fix APIImporter broken after one recent rebase

Summary
🐛 Syncer: fix APIImporter broken after one recent rebase
Related issue(s)
Issue met while doing manual tests for PR https://github.com/kcp-dev/kcp/pull/2336

/lgtm

/approve


[magnum-auto-healer] Update cluster health status only when needed

Added check before updating cluster health status.

What this PR does / why we need it:
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

/approve


save state to local storage

and offer the user when he starts up the site to restart an old session or make a new one. (modal window -> https://react-bootstrap.github.io/components/modal/)

resolved by #97


Upgrading a package fails with io.UnsupportedOperation: write

Doing this fails:
mox install pcaversaccio/snekmate
mox install<EMAIL_ADDRESS>
or
mox install<EMAIL_ADDRESS>mox install<EMAIL_ADDRESS>

fixed in https://github.com/Cyfrin/moccasin/pull/55


qmapshack: 1.17.0 -> 1.17.1

Description of changes
Diff: https://github.com/Maproom/qmapshack/compare/V_1.17.0...V_1.17.1
Changelog: https://github.com/Maproom/qmapshack/blob/V_1.17.1/changelog.txt

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 273852 run on x86_64-linux 1

1 package built:

qmapshack


SourceMap performance issue

Describe the bug
Input: A large bundle generated by webpack.
minify: 2s without sourcemap, and 20s with sourcemap
When minify and transform very large file, enable source map will have huge impact on performance, very huge impact that sometimes even slower than terser.
Reprod repo here
Config
No response
Playground link
As the file is too large, I think we better download the reprod repo locally
Expected behavior
SourceMap should be slow to generate, but shouldn't be this slow
Actual behavior
2s without sourcemap
20s with sourcemap
Version
1.3.14
Additional context
No response

Additional information.
MacOs Monterey 12.1
CPU: 2.6 GHz Intel Core i7
32 GB mem

@kdy1  It seems that if the sourcefile contains lots chinese characters it will have serious performance problems, most of the time are spent on

compared to asci-only file

when I remove all the chinese character from code, the sourcemap generation cost reduce from 37s to 1s

@hardfist Can you share a test input?

@kdy1 https://github.com/hardfist/swc-minify-perf/blob/main/BizCharts.js

Let's see if https://github.com/swc-project/swc/pull/6523 fixes it.
Performance issue is fixed, but I'm not sure if all souremap tests will pass

Thanks !


package name wrong in CJS package.json after build_all

It currently sets the name to "name": "rxjs-es6" in the dist/cjs/directory. That needs to be"name": "rxjs"` only.
In the dist/es6/ directory, the name now needs to be set to "name": "rxjs-es", it's also currently wrong.

cc/ @robwormald @jeffbcross

https://github.com/ReactiveX/RxJS/pull/895

FTR my change didn't introduce this behavior :).

I'm closing this issue since #895 is merged.


Chromatic for Pull Requests

Fixes #97.

Just want a quick two thumbs up so we can get this in. I just thought I'd slow down on auto merging ALL my code.


Release the index.d.ts file

two months ago, You added an index.d.ts but seems like it's not been released to npm yet. I want to use this in the tailwind.config.ts file but I get an error because there is no declaration file. I double-checked npm and the node_modules there is no this file:
https://github.com/jamiebuilds/tailwindcss-animate/blob/cb49af9493e666b905717d4e6aa40e2e69285517/index.d.ts#L1-L3

Published


Migrate federalist content to cloud.gov pages

In order to migrate Federalist to CG Pages, we want add content from the federalist.18f.gov site into the cloud.gov site. To facilitate the migration, the following tasks can released independently to cloud.gov to be as transparent as possible. This is larger epic issue that will continue to change as the migration progresses.
Acceptance Criteria Tasks

[ ] Create an announcement page on cloud.gov
[ ] Add a new landing page based on the content from federalist.18f.gov under cloud.gov/pages
[ ] Add product features to cloud.gov
[ ] Add customer success stories to cloud.go
[ ] Migrate docs
[ ] TBD

Security considerations
none

Confirmed with @drewbo this is no longer needed


ImportError: cannot import name 'Cache' from 'aiocache'

aiocache==0.10.1
doesn't have the latest changes.
Got this error when running example:
from aiocache import Cache
ImportError: cannot import name 'Cache' from 'aiocache'

Iep, latest changes from master are not published yet


Add route for accessing CLTK tokenizer

Reference https://github.com/cltk/cltk_api/issues/20 for the original conversation about this.

As I mentioned on Gitter, I'd like to think about the routing for all NLP in the API. Is this task at all urgent for you, Luke?

I would like to work on this.
@lukehollis It would be helpful, if you could provide some more details.

Not at all urgent--just coming from the interest in the topic in #20. Will let you follow up here.

Sorry, looks like this is a part of https://github.com/cltk/cltk_api/issues/28 and will assign to @Imran31


No option to limit fzf to the current directory?

Category

[x] fzf binary
[ ] fzf-tmux script
[ ] Key bindings
[ ] Completion
[ ] Vim
[ ] Neovim
[ ] Etc.

Shell

[x] bash
[ ] zsh
[ ] fish

Am I missing something, or there's no option to limit fzf to the current directory only and not to go down recursively? Something like --maxdepth?
And (for now?) this is only possible if the FZF_DEFAULT_COMMAND is set to something like ag or rg?

fzf is a unix filter, like grep. It doesn't know what each line means.
seq 1000 | fzf

You can set FZF_DEFAULT_COMMAND to find command with -maxdepth option.

For all the lost souls like me before figuring it out. Testes on macOS with zsh:
Add this to ~/.zshrc
export FZF_DEFAULT_COMMAND="find . -maxdepth 1"
export FZF_CTRL_T_COMMAND="$FZF_DEFAULT_COMMAND"

And then instead of cd **[TAB]  use cd [ctrl+t] and you should get file list only 1 level deep .

Further to @vorg's suggestion, you can use sed to remove the annoying first two characters ./ of every line, which take up valuable screen real state.
export FZF_DEFAULT_COMMAND="find . -maxdepth 1 | sed 's/^..//'"

For all the lost souls like me before figuring it out. Tested on macOS with zsh:
Add this to ~/.zshrc
export FZF_DEFAULT_COMMAND="find . -maxdepth 1"
export FZF_CTRL_T_COMMAND="$FZF_DEFAULT_COMMAND"

And then instead of cd **[TAB] use cd [ctrl+t] and you should get file list only 1 level deep .

bless you.

If your directories are separated using [ / ], then you can use:

fzf + [enter] = start fuzzy search

type !/ = exclude lines with backslash

If you want to further limit search to let's say dotless files, you can extend fzf search with:

type !^. = exclude files starting with dot

If your directories are separated using [ / ], then you can use:

fzf + [enter] = start fuzzy search

type !/ = exclude lines with backslash

If you want to further limit search to let's say dotless files, you can extend fzf search with:

type !^. = exclude files starting with dot

If you want to see also directories in current folder, you could do:
fzf < <(fd --max-depth 1)
Too much to type out? Add alias to .bashrc or .zshrc file:
     # [ fzfc ]= fuzzy search current
fzfc='fzf < <(fd --max-depth 1)'

For all the lost souls like me before figuring it out. Tested on macOS with zsh:
Add this to ~/.zshrc
export FZF_DEFAULT_COMMAND="find . -maxdepth 1"
export FZF_CTRL_T_COMMAND="$FZF_DEFAULT_COMMAND"

And then instead of cd **[TAB] use cd [ctrl+t] and you should get file list only 1 level deep .

THANK YOU SO SO MUCH


operator kiali (1.73.0)

Thanks submitting your Operator. Please check below list before you create your Pull Request.

/merge possible

/merge possible


snowflake terraform resource not escaping backslashes properly when imported

Provider Version:
0.25.35 (current latest)
Terraform Version :
1.1.3
Describe the bug
We are seeing inconsistent character escaping when performing terraform import versus terraform apply. Quick example to reproduce the bug:

Make sure logging level is INFO. export TF_LOG=INFO

In snowflake, create a file_format resource like so. Take special note that escaping unenclosed fields is 1 escaped backslash.
CREATE FILE FORMAT DB1.SCHEMA1.CSV TYPE = 'CSV' ESCAPE_UNENCLOSED_FIELD = '\\'

Create 2 nearly-identical Terraform resources. 1 to mirror the remote state, and 1 we are going to create via terraform apply.  The only field you need to pay attention to is escape_unenclosed_field.

resource "snowflake_file_format" "db1_schema1_csv" {
  escape_unenclosed_field        = "\\"
  name                           = "CSV"
  database                       = "DB1"
  schema                         = "SCHEMA1"
  format_type                    = "CSV"
  binary_format                  = "HEX"
  compression                    = "AUTO"
  date_format                    = "AUTO"
  empty_field_as_null            = true
  encoding                       = "UTF8"
  error_on_column_count_mismatch = true
  escape                         = "NONE"
  field_delimiter                = ","
  field_optionally_enclosed_by   = "NONE"
  null_if                        = [
    "\\N",
  ]
  record_delimiter               = <<-EOT

EOT
  skip_byte_order_mark           = true
  time_format                    = "AUTO"
  timestamp_format               = "AUTO"
  validate_utf8                  = true
}

resource "snowflake_file_format" "db1_schema1_csv2" {
  escape_unenclosed_field        = "\\"
  name                           = "CSV2"
  database                       = "DB1"
  schema                         = "SCHEMA1"
  format_type                    = "CSV"
  binary_format                  = "HEX"
  compression                    = "AUTO"
  date_format                    = "AUTO"
  empty_field_as_null            = true
  encoding                       = "UTF8"
  error_on_column_count_mismatch = true
  escape                         = "NONE"
  field_delimiter                = ","
  field_optionally_enclosed_by   = "NONE"
  null_if                        = [
    "\\N",
  ]
  record_delimiter               = <<-EOT

EOT
  skip_byte_order_mark           = true
  time_format                    = "AUTO"
  timestamp_format               = "AUTO"
  validate_utf8                  = true
}

Run terraform import snowflake_file_format.db1_schema1_csv 'DB1|SCHEMA1|CSV'

Again, the only field you need to pay attention to is escape_unenclosed_field. Try running terraform apply.  You'll get a SQL Compilation error.

| Error: error creating file format CSV2: 001003 (42000): SQL compilation error:
│ syntax error line 2 at position 196 unexpected '' NULL_IF = (''.
│ syntax error line 2 at position 210 unexpected '\N'.
│ parse error line 2 at position 425 near '<EOF>'.

If you set TF_LOG=INFO earlier, you'll see the snowflake query used to create the file_format. Full SQL command here.
CREATE FILE FORMAT "DB1"."SCHEMA1"."CSV2" TYPE = 'CSV' COMPRESSION = 'AUTO' RECORD_DELIMITER = '
  ' FIELD_DELIMITER = ',' DATE_FORMAT = 'AUTO' TIME_FORMAT = 'AUTO' TIMESTAMP_FORMAT = 'AUTO' BINARY_FORMAT = 'HEX' ESCAPE = 'NONE' ESCAPE_UNENCLOSED_FIELD = '\' FIELD_OPTIONALLY_ENCLOSED_BY = 'NONE' NULL_IF = ('\N') ENCODING = 'UTF8' SKIP_BLANK_LINES = false TRIM_SPACE = false ERROR_ON_COLUMN_COUNT_MISMATCH = true REPLACE_INVALID_CHARACTERS = false VALIDATE_UTF8 = true EMPTY_FIELD_AS_NULL = true SKIP_BYTE_ORDER_MARK = true

Specifically you'll notice the query contains the following: ESCAPE_UNENCLOSED_FIELD = '\' , a single backslash, which is causing the error since SQL is escaping the '.
In summary:

CSV1 was imported, and is consistent with the remote state. (ESCAPE_UNENCLOSED_FIELD shows '\\')
CSV2 we tried to create like CSV1 with identical parameters, but it failed. The workaround is to double escape ESCAPE_UNENCLOSED_FIELD = '\\\\' to get it to work, but now we have a glaring inconsistency where CSV1 has '\\' and CSV2 has '\\\\'

Expected behavior
I don't really want to have to double escape things, but I will if it's necessary. Either way, I would expect import and apply to be consistent how escaped characters are handled.
Side note for file_format, leaving optional fields blank make them null instead of the default values. Notice the CREATE FILE FORMAT snowflake command, the only optional value I wanted to set was escape_unenclosed_field but in terraform I had to set all of them. I expected omitting them would choose the snowflake default value, but terraform sets them to null instead of the default values

I imagine the least "breaking" solution would be to focus on changing terraform import to escape incoming strings. Turning newlines into '\n' instead of actual newlines, turning \\ into \\\\, etc.
It wouldn't harm people's pre-existing terraform code that way

I'm facing the same issue with the null_if parameter of snowflake_file_format.
I am currently forced to import file_formats into terraform due to #1147. There is also a problem where optional fields for snowflake_file_format try to get set to null if not specified. So I specified everything affected explicitly.
Here is the terraform definition, backslashes are double escaped in null_if otherwise the wrong SQL is generated with NULL_IF = ('\N') instead of the needed NULL_IF = ('\N') on the Snowflake query side.
resource "snowflake_file_format" "pipelinewise_target_snowflake_csv" {
  name                           = "PIPELINEWISE_TARGET_SNOWFLAKE_CSV"
  database                       = snowflake_database.environment_database_raw.name
  schema                         = snowflake_schema.environment_database_raw_common.name
  format_type                    = "CSV"
  escape                         = "\\"
  field_optionally_enclosed_by   = "\""
  empty_field_as_null            = true
  error_on_column_count_mismatch = true
  skip_byte_order_mark           = true
  null_if                        = [ "\\\\N" ] # there seems to be
  binary_format                  = "HEX"
  compression                    = "AUTO"
  date_format                    = "AUTO"
  encoding                       = "UTF8"
  escape_unenclosed_field        = "\\"
  field_delimiter                = ","
  record_delimiter               = <<-EOT

  EOT
  time_format                    = "AUTO"
  timestamp_format               = "AUTO"

  lifecycle {
    ignore_changes = [
      # workaround for https://github.com/Snowflake-Labs/terraform-provider-snowflake/issues/1147
      # these will be manually created, imported and ignore the option until resolved
      validate_utf8
    ]
  }
}

To workaround the other issue, I try to apply with Terraform to get the CREATE FILE FORMAT query that fails and modify it slightly before importing.
CREATE FILE FORMAT "SANDBOX"."COMMON"."PIPELINEWISE_TARGET_SNOWFLAKE_CSV" TYPE = 'CSV' COMPRESSION = 'AUTO' RECORD_DELIMITER = '
' FIELD_DELIMITER = ',' DATE_FORMAT = 'AUTO' TIME_FORMAT = 'AUTO' TIMESTAMP_FORMAT = 'AUTO' BINARY_FORMAT = 'HEX' ESCAPE = '\\' ESCAPE_UNENCLOSED_FIELD = '\\' FIELD_OPTIONALLY_ENCLOSED_BY = '"' NULL_IF = ('\\N') ENCODING = 'UTF8' SKIP_BLANK_LINES = false TRIM_SPACE = false ERROR_ON_COLUMN_COUNT_MISMATCH = true REPLACE_INVALID_CHARACTERS = false EMPTY_FIELD_AS_NULL = true SKIP_BYTE_ORDER_MARK = true

After creation, I import the resource into state. Running a plan after import now attempts to change the NULL_IF to "\N" on Terraform's side which breaks the file format as it translates to NULL_IF = ('\N') on the Snowflake query.
  ~ resource "snowflake_file_format" "pipelinewise_target_snowflake_csv" {
        id                             = "SANDBOX|COMMON|PIPELINEWISE_TARGET_SNOWFLAKE_CSV"
        name                           = "PIPELINEWISE_TARGET_SNOWFLAKE_CSV"
      ~ null_if                        = [
          - "\\N",
          + "\\\\N",
        ]
        # (32 unchanged attributes hidden)
    }

As a workaround, I am adding null_if to ignore_changes to prevent it from breaking the working file format definition.

We are closing this issue as part of a cleanup described in announcement. If you believe that the issue is still valid in v0.89.0, please open a new ticket.


[Feature request] data output (no obd)

Hi. Im wondering if i can use openpilot on ubuntu computer without panda or any other hardware. Just laptop with ubuntu, 2 webcams and arduino.
So openpilot would output values to selected com port (arduino) and arduino would take control of retrofitted components in any old car.
Everyone should program arduino by themself as its program would depend on retrofitted components.

There's an example of something like this used for simulation. See tools/sim/bridge.py.


Javascript .query() method doesn't work

I had some client-side JS code written a few weeks ago that would work normally with InfluxDB. I just checked back now, and it no longer works. I couldn't get to the bottom of the issue, but it seems that it may have been caused by an update to the JS file..
This is the code:
influxdb = new InfluxDB({
  "host" :"104.131.XX.XX",
  "port" :"8086",
  "username" :"root",
  "password" :"root",
  "database" :"data"
  });
influxdb.query("select min(value) from a_series group by time(1d)")
    .then(function(a) { ... })

This creates this query:
curl 'http://104.131.XX.XX:8086/query?u=root&p=root&q=select%20min(value)%20from%20a_series%20group%20by%20time(1d)'

And returns this error:
{"results":[{"error":"database not found: "}]}

When I try to run the query manually from within the admin interface,
curl 'http://104.131.XX.XX:8086/query?u=root&p=root&q=select%20min(value)%20from%20a_series%20group%20by%20time(1d)&db=data'

So it seems that the JS client is not adding the db=data at the end of the URL for some reason? Any ideas why this may be? The client hasn't been changed in a while, and this code used to work just fine.. Also, I couldn't track down the Angular code that runs in the admin interface, but I guess it doesn't call the influxdb.query() method?
I'm using this version of the JS client: http://get.influxdb.org/influxdb-latest.js

When you say "used to work", do you mean against 0.8? The 0.9 API changed significantly and it is possible this client code will not work with 0.9.

I was using the CDN version of the JS library: http://get.influxdb.org/influxdb-latest.js. My 0.9-rc20 version came with an Angular app that references a version named influxdb-0.8.999.js.
So the solution to my problem of the db field not getting appended to the URL was to use the queryDatabase call instead of query. This method exists in influxdb-0.8.999.js but not in influxdb-latest.js. I also searched the influxdb-js repo for this method, but can't find it there either:
https://github.com/influxdb/influxdb-js/search?q=queryDatabase
I still don't know what's going on. Isn't the "unstable" version of the JS code that comes with the influxd RC binary not tracked on github? (Also not documented...). And the influxdb-latest.js does not work with the 0.9 version of the server (i.e., it's the latest stable release?).
Thanks!

Packages marked "latest" are only for 0.8 software, since 0.9 is considered
unstable and is in alpha stage right now. So using that JS client with
InfluxDB 0.9 will not work.
Philip
On Wed, Apr 29, 2015 at 4:55 PM, Berk Birand<EMAIL_ADDRESS>wrote:

I was using the CDN version of the JS library:
http://get.influxdb.org/influxdb-latest.js. My 0.9-rc20 version came with
an Angular app that references a version named influxdb-0.8.999.js.
So the solution to my problem of the db field not getting appended to the
URL was to use the queryDatabase call instead of query. This method
exists in influxdb-0.8.999.js but not in influxdb-latest.js. I also
searched the influxdb-js repo for this method, but can't find it there
either:
https://github.com/influxdb/influxdb-js/search?q=queryDatabase
I still don't know what's going on. Isn't the "unstable" version of the JS
code that comes with the influxd RC binary not tracked on github? (Also not
documented...). And the influxdb-latest.js does not work with the 0.9
version of the server (i.e., it's the latest stable release?).
Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/influxdb/influxdb/issues/2447#issuecomment-97616774.

Not a bug with influxdb/influxdb. Please open an issue on the client repo.

Thanks for the reply, Philip! I gathered as much about the JS versions.
The "latest" one somehow did work with my RC version a few weeks back,
but then was changed (which is completely legit - I should have used a
local copy).
The mystery for me is now to get the source code of
"influxdb-0.8.999.js" which, despite it's name, is actually for v0.9.
This version doesn't seem to be on any of the branches of the
influxdb-js repo?
As a general note, having a version be a "release candidate" is very
different to calling it "alpha". Given that the documentation is
non-existent, I suppose it's closer to that than to an RC release:
http://influxdb.com/docs/v0.9/clients/javascript.html
I would not have downloaded this version if it was appropriately labeled
"alpha" so as not to get into these types of issues.
otoolep wrote:

Packages marked "latest" are only for 0.8 software, since 0.9 is considered
unstable and is in alpha stage right now. So using that JS client with
InfluxDB 0.9 will not work.
Philip
On Wed, Apr 29, 2015 at 4:55 PM, Berk Birand<EMAIL_ADDRESS>wrote:

I was using the CDN version of the JS library:
http://get.influxdb.org/influxdb-latest.js. My 0.9-rc20 version came with
an Angular app that references a version named influxdb-0.8.999.js.
So the solution to my problem of the db field not getting appended to the
URL was to use the queryDatabase call instead of query. This method
exists in influxdb-0.8.999.js but not in influxdb-latest.js. I also
searched the influxdb-js repo for this method, but can't find it there
either:
https://github.com/influxdb/influxdb-js/search?q=queryDatabase
I still don't know what's going on. Isn't the "unstable" version of
the JS
code that comes with the influxd RC binary not tracked on github?
(Also not
documented...). And the influxdb-latest.js does not work with the 0.9
version of the server (i.e., it's the latest stable release?).
Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/influxdb/influxdb/issues/2447#issuecomment-97616774.

—
Reply to this email directly or view it on GitHub
https://github.com/influxdb/influxdb/issues/2447#issuecomment-97900162.

Will do. Although the issues regarding version naming are extremely relevant..