Allow empty text for PlainTextBindings

[ml-relic]

Confirmation

• [X] My issue isn't already found on the issue tracker.
• [X] I have replicated my issue using the latest version of the library and it is still present.

cloudflare-go version

v0.100.0

Go environment

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/ml/Library/Caches/go-build'
GOENV='/Users/ml/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/ml/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/ml/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.5/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.5/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.5'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/ml/terraform-provider-cloudflare/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/5n/6sm8h7cs3sv6xtd00j2tt_j80000gp/T/go-build3563532188=/tmp/go-build -gno-record-gcc-switches -fno-common'

Expected output

Running terraform apply with the following worker configuration, notably plain text binding, should succeed:

resource "cloudflare_workers_script" "empty_blinding_edge_worker" {
  account_id = var.cloudflare_account_id
  name       = "empty_binding_edge_worker"
  content    = file("worker.js")

  plain_text_binding {
    name = "MORE_BLANK_TEXT"
    text = ""
  }
}

Empty PlainTextBindings are supported by the Cloudflare UI as well as the API itself. UI:

API:

curl --request PUT \
--url https://api.cloudflare.com/client/v4/accounts/<account_id>/workers/scripts/edge-worker \
--header 'X-Auth-Email: <email>' \
--header 'X-Auth-Key: <api-token>' \
--header 'Content-Type: multipart/form-data' \
--form 'script=@/Users/ml/worker.js;type=application/javascript' \
--form 'metadata=@/Users/ml/metadata.json;type=application/json'

metadata.json looks like the following:

{"body_part":"script","bindings":[{"name":"BLANK_TEXT","text":"","type":"plain_text"},{"name":"MY_EXAMPLE_PLAIN_TEXT","text":"foobar","type":"plain_text"}],"logpush":false,"tags":null}

Actual output

cloudflare_workers_script.empty_blinding_edge_worker: Modifying... [id=empty_binding_edge_worker]
╷
│ Error: error updating worker script: text for binding "MORE_BLANK_TEXT" cannot be empty
│ 
│   with cloudflare_workers_script.empty_blinding_edge_worker,
│   on worker.tf line 1, in resource "cloudflare_workers_script" "empty_blinding_edge_worker":
│    1: resource "cloudflare_workers_script" "empty_blinding_edge_worker" {
│ 
╵

Code demonstrating the issue

From https://github.com/cloudflare/cloudflare-go/blob/master/workers_bindings.go#L214-L216:

func (b WorkerPlainTextBinding) serialize(bindingName string) (workerBindingMeta, workerBindingBodyWriter, error) {
	if b.Text == "" {
		return nil, nil, fmt.Errorf(`text for binding "%s" cannot be empty`, bindingName)
	}

	return workerBindingMeta{
		"name": bindingName,
		"type": b.Type(),
		"text": b.Text,
	}, nil, nil
}

Steps to reproduce

Use the following terraform to try and create a simple worker with an empty plain text binding:

resource "cloudflare_workers_script" "empty_blinding_edge_worker" {
  account_id = "<account-id>"
  name       = "empty_binding_edge_worker"
  content    = file("worker.js")

  plain_text_binding {
    name = "EVEN_MORE_BLANK_TEXT"
    text = ""
  }
}

worker.js

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  return new Response('Hello Worker!');
}

Running terraform apply will produce an error indicating that the text for the binding cannot be empty. This behavior differs from that of the UI and API though. In order to replicate with the UI/API, see Expected output section above.

References

No response