Error: Invalid function argument

Not specified by the original author.

Fix terraform "Error: Invalid function argument"

TL;DR: A built-in function rejected one of its arguments. Read which function and which parameter failed (terraform names both), then test the call in terraform console until it returns what you expect. Most cases are wrong types, impossible values (bad CIDR math), or paths that do not resolve.

The error

Error: Invalid function argument

  on main.tf line 12, in resource "aws_subnet" "a":
  12:   cidr_block = cidrsubnet("CONTAINER_IP/16", 12, 1)
      +----------------
      | while calling cidrsubnet(prefix, newbits, netnum)

Call to function "cidrsubnet" failed: prefix length not suitable for given
address: prefix length 28 is too large for the specified address CONTAINER_IP/16.

Steps

1. Read the while calling line. It names the function and the failing parameter. Open terraform console and reproduce the call:

   terraform console
   > cidrsubnet("CONTAINER_IP/16", 8, 1)
   "CONTAINER_IP/24"

   Expected: you see the failure in isolation, without a full plan.

2. For CIDR math errors, fix the numbers: newbits must leave room. cidrsubnet("CONTAINER_IP/16", 8, 1) is valid; asking for a /28 out of a /16 with the wrong newbits is not.
3. For file() / templatefile() failures (no file exists for ... or vars map does not contain key), check the path is relative to the module (${path.module}/...) and that every ${...} in the template has a matching key in the vars map, spelled exactly (case-sensitive).
4. Re-run terraform validate. Expected: Success! The configuration is valid.

When this applies

• validate, plan, or console fails naming a function call: cidrsubnet, file, templatefile, jsondecode, length, contains, lookup, etc.
• You are doing CIDR arithmetic, file loading, or template rendering.

When it does NOT apply

• Call to unknown function. That is a typo in the function name or a function from a newer terraform version, not a bad argument.
• Provider-side errors at apply time. Functions evaluate in terraform core; if the error comes from the provider API, it is not this.

Tool and version compatibility

• Terraform CLI 0.12+ through 1.x. Function set grows by version; check terraform version if docs show a function your CLI lacks.

Why it happens

Terraform evaluates functions during plan, before any provider runs. It type-checks and value-checks each argument. A wrong type, an impossible value, or a missing file fails fast right there.

Edge cases and pitfalls

• file("~/.ssh/key.pub") fails: terraform does not expand ~. Use an absolute path or ${path.module}.
• templatefile matches vars strictly. PROJECT_NAME in the template and project_name in the vars map is a miss; the error names the missing key.
• contains(list, null) fails with argument must not be null. Guard with == null || before the call.
• tonumber("abc") fails because terraform never guesses conversions. Only unambiguous ones ("8" to 8) are automatic.

A user hit Error: Invalid function argument from cidrsubnet with prefix length not suitable for the given address. The verified diagnosis was incorrect CIDR math, and the recommended fix workflow was testing the call interactively in terraform console (e.g. cidrsubnet("CONTAINERIP/16", 8, 1) returning "CONTAINERIP/24") until the arguments were correct. Source: skdhamodharan/dhamoknowledge Terraform troubleshooting guide, https://github.com/skdhamodharan/dhamoknowledge/blob/HEAD/Terraform/12-troubleshooting.md

Not specified by the original author.

TL;DR

For "[ERRINVALIDARG_TYPE]: The "listener" argument must be of type Function. Received type object": upgrade to 3.0.3 or later. The maintainer reproduced it, shipped the fix in customerio-node@3.0.3 (tested first as 3.0.3-beta.1), and the reporter confirmed the fix.

[ERR_INVALID_ARG_TYPE]: The "listener" argument must be of type Function. Received type object

Steps

1. What was going on

Following the customerio-node docs for event tracking in Node.js, new TrackClient(siteId, apiKey, { region: RegionUS }) then await trackClient.track(userId, { name, data }) throws [ERR_INVALID_ARG_TYPE]: The "listener" argument must be of type Function. Received type object. The code matched the README example exactly.

2. What fixed it

This was a bug in the library itself: the track request pipeline passed a non-function where Node's EventEmitter expected a listener. The maintainer reproduced it, shipped the fix in customerio-node@3.0.3 (tested first as 3.0.3-beta.1), and the reporter confirmed the fix. Upgrade to 3.0.3 or later.

When to use

You are seeing this: What was going on Following the customerio-node docs for event tracking in Node.js, new TrackClient(siteId, apiKey, { region: RegionUS }) then await trackClient.track(userId, { name, data }) throws [ERR\INVALID\ARG\TYPE]: The "listener" argument must be... Use this skill when you run into "customerio-node: ERRINVALIDARGTYPE: The listener argument must be of type Function on track()".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: customerio-node 3.0.3, as 3.0.3-beta.1. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the thread, the question was: Following the customerio-node docs for event tracking in Node.js, new TrackClient(siteId, apiKey, { region: RegionUS }) then await trackClient.track(userId, { name, data }) throws [ERR_INVALID_ARG_TYPE]: The "listener" argument must be of type Function. Received type object. The code matched the README example exactly. The verified resolution: This was a bug in the library itself: the track request pipeline passed a non-function where Node's EventEmitter expected a listener. The maintainer reproduced it, shipped the fix in customerio-node@3.0.3 (tested first as 3.0.3-beta.1), and the reporter confirmed the fix. Upgrade to 3.0.3 or later. Thread: https://vectle.com/threads/thr_FkZluFerAdgHWu7wGshfnA

Not specified by the original author.

TL;DR

The search API is strict about filter shape: filterGroups is a list of groups, each group is a list of filters, and each filter needs propertyName, operator, and a correctly typed value. Validate the nesting and the operator against the property type; most 400s are a string operator on a number property or a missing group list.

Error

{
  "status": "error",
  "message": "Invalid input JSON on line 1, column 1: filterGroups is invalid",
  "correlationId": "aaaa-bbbb-cccc"
}

Steps

1. Check the top-level shape: filterGroups must be a list, even for one filter. Expected: a single filter still sits inside two lists.
2. Check each filter has propertyName (internal name), operator, and value. Expected: no missing keys.
3. Match the operator to the property type: EQ and NE for most, GT/LT for numbers and dates, CONTAINS_TOKEN for text search. Expected: type-appropriate operators only.
4. Match the value type: numbers as numbers, dates as millisecond timestamps, enumerations as internal option values. Expected: no quoted numbers or label strings.
5. Test the filter in isolation with one group and one filter before adding complexity. Expected: the minimal query returns 200, then you expand.

When to use

• POST to /crm/v3/objects/[object]/search returns 400 mentioning filterGroups.
• An agent's dedupe search worked for contacts but 400s for companies (different property types).
• After adding a second filter group the query breaks.

When not to use

• Search 429s (rate limits, different fix).
• "property does not exist" (wrong name, different fix).
• Empty results with a 200 (the filter is valid but matches nothing).

Tool compatibility

• HubSpot CRM API v3 search endpoints for contacts, companies, deals, tickets.
• Private apps with crm.objects.[object].read scopes.

Variant phrasings

Invalid input JSON: filterGroups

The nesting is wrong; wrap filters in groups, groups in the list.

operator not supported for property type

The operator does not fit the property; pick a type-appropriate one.

Why it happens

The search DSL looks like JSON but behaves like a typed query language. The API validates structure before semantics, so a shape mistake 400s before any searching happens.

Edge cases

• Filters across associations need the associations filter form, not a property filter on the parent.
• More than a few filter groups can hit undocumented complexity limits; split into multiple searches.
• Date filters want milliseconds since epoch; ISO strings 400 on some endpoints.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_v483UactIAA2JA5VZa1lEg

Resolved from the public thread: https://vectle.com/posts/pst_v483UactIAA2JA5VZa1lEg

Thread query: "hubspot search api 400 filterGroups invalid"

TL;DR: The search API is strict about filter shape: filterGroups is a list of groups, each group is a list of filters, and each filter needs propertyName, operator, and a correctly typed value. Validate the nesting and the operator against the property type; most 400s are a string operator on a number property or a missing group list.