I have the exact same issue.

Another "me too" comment.

+1

PR #2420 fixed the consistency model as the provider currently uses team ID internally for all team resources. You can stop the churn by using a github_team data source to lookup your team ID and you will be using fewer API requests than the old resource used to make prior to #2420.

Take a look at the hoops I've had to jump through to convert team slugs into ids for a bunch of repos defined in human-curated json files, and tell me again how great it is that the provider uses fewer API requests:

locals {
  repo_files    = fileset(path.module, "repository_data/*.json")
  raw_repo_data = [for f in local.repo_files : jsondecode(file(f))]

  repo_data = [
    for repo in local.raw_repo_data : {
      for k, v in repo : k =>
      k == "collaborators" ?
      {
        for k2, v2 in v : k2 =>
        k2 == "teams" ? [
          for block in v2 : {
            for k4, v4 in block : k4 =>
            k4 == "slug" ? local.team_ids[v4] : v4
          }
        ]
        : v2
      }
      : v
    }
  ]

  # Get the set of github team slugs used by all repositories
  team_slugs = toset(
    flatten( # W: local.teams is declared but not used
      [
        for name, repo in local.raw_repo_data : [
          for team in lookup(repo.collaborators, "teams", []) :
          team.slug
        ]
      ]
    )
  )

  team_ids = {
    for team in data.github_team.this : team.slug => team.id
  }
}

data "github_team" "this" {
  for_each = local.team_slugs
  slug     = each.value
}

Concur with the above.

I see what we /could/ do, but if you look at the example in the other comment, we're effectively asked to implement all the logic that should be in a provider, on top of the provider in the resource definition. At the topmost abstraction, the resource definition layer (our terraform code) lookups of foundational references should be invisible... and the contested provider code clearly shows this behavior (but flipped from invisibly looking up one thing to invisibly looking up some other thing instead)

@robinbowes @JCY-Alchemy I've just re-checked my notes and this is a defect as I'd intended to not churn on slugs. There are no automated acceptance tests here (I'm working on it) and I don't work at GitHub so don't have easy access to test infrastructure. I've got a PR open to work on this resource so I'll figure out why this isn't working and add a fix.

FYI the reason the number of API call matter is that prior to the refactor this resource was unusable at anything approaching scale.