Composer Build issue with Google Vendor Libraries

Facing the same issue when the following PHP extinctions are not installed in the system.

grpc and protobuf

    "conflict": {
        "ext-protobuf": "<3.7.0"
    },

  "suggest": {
    "ext-protobuf": "For better performance, install the protobuf C extension.",
    "google/protobuf": "To get started using grpc quickly, install the native protobuf library."
  },

The google/analytics-data for GA4 needs them.

This module may end up adding the following to the composer.json

  "ext-protobuf": "*",
  "ext-grpc": "*",

To make sure that the google/protobuf, google/grpc-gcp and grpc/grpc PHP libraries are working in the right way.

Or the following issues will happen

PHP Fatal error:  Failed to parse binary descriptor
 in /app/vendor/google/analytics-data/metadata/V1Beta/Data.php on line 288

Likely the same cause as I'm encountering after just installing on my local development containers:

Call to undefined function Google\Protobuf\Internal\bccomp() in Google\Protobuf\Internal\Message->convertJsonValueToProtoValue() (line 961 of [path to site]/vendor/google/protobuf/src/Google/Protobuf/Internal/Message.php).

This occurs every time I try to view the analytics, either in the default Summary view or in per-page views.

To address the OP, this appears to be an issue with google/protobuf in cloud environments. This is the corresponding issue on their github: https://github.com/protocolbuffers/protobuf/issues/11203

wsantell pointed out to be that there was a Binary diff in the files (the text looked the same but if you did a binary comparison there was a difference) I then started comparing the files sha1 hash to see if they were the same on local development environments as they were in deployed environments.

We were able to track this down to the fact that a lot of these Google libraries are compiling their code... if you look at the top of vendor/google/analytics-data/metadata/V1Alpha/Data.php you will see

<?php
# Generated by the protocol buffer compiler.  DO NOT EDIT!
# source: google/analytics/data/v1beta/data.proto

namespace GPBMetadata\Google\Analytics\Data\V1Beta;

class Data
{
    public static $is_initialized = false;

    public static function initOnce() {
        $pool = \Google\Protobuf\Internal\DescriptorPool::getGeneratedPool();

        if (static::$is_initialized == true) {
          return;
        }
        $pool->internalAddGeneratedFile(
            '
<AF>:
\'google/analytics/data/v1beta/data.proto^R^\google.analytics.data.v1beta"?
        DateRange^R^R

start_date^X^A ^A(      ^R^P
^Hend_date^X^B ^A(      ^R^L
^Dname^X^C ^A(  "<83>^A
^KMinuteRange^R^^

those special characters are compiled code, unfortunately Git expects *.php files to be text so when your CI/CD system is auto bulding your code base and committing to Git you will see this message

warning: CRLF will be replaced by LF in vendor/google/analytics-data/metadata/V1Beta/Data.php.

Git is supposed to replace the LF with CRLF when the code is checked back out but this breaks the compiled code.

I searched grep -Rn "Generated by the protocol buffer compiler. DO NOT EDIT!" vendor and found the seemingly all of the Google packages that are being required by this module use some files with compiled code.

The solution we came up with is to add the following to the composer.json in the scripts.post-drupal-scaffold-cmd array (so after DrupalScaffold puts all the files in place it will add a a new file at vendor/google/.gitattributes )

echo '** -text diff' >> vendor/google/.gitattributes

This tells Git to treat all files in these packages as non-text (binary files) so Git will not change any line endings and will therefore not break the files.

@jrglasgow we were bitten by this too (for a different library though, dialogflow-cloud - but uses protobuf library for instance which has compiled files as well).

I've tried your suggestion of the attributes but that didn't seem to fix it (even after removing, committing, requiring, adding the files again to git)

What fixed it in the end, was removing and requiring the library on the server with composer.
The crazy part here, is that git didn't see any differences, but at that point, everything started working.

This is, and that's an understatement, very weird behavior, wow! :)

I followed the steps found here to get around the issues with the Google-provided code by manually uploading the files in a binary transfer format but, now, I am getting this database error.

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'conversions:click' for key 'PRIMARY': INSERT INTO "google_analytics_reports_fields" ("type", "ui_name", "description", "gaid", "data_type", "column_group", "calculation") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => METRIC [:db_insert_placeholder_1] => Conversions count for click [:db_insert_placeholder_2] => The count of a specific conversion event. [:db_insert_placeholder_3] => conversions:click [:db_insert_placeholder_4] => string [:db_insert_placeholder_5] => Event [:db_insert_placeholder_6] => ) in Drupal\mysql\Driver\Database\mysql\ExceptionHandler->handleExecutionException() (line 50 of /code/web/core/modules/mysql/src/Driver/Database/mysql/ExceptionHandler.php).

Any ideas on how to handle it? I do not want to sound like a jerk, but as of this writing, GA4 goes live in 28 days so being able to continue to use the module after Universal Analytics is disabled is somewhat time-sensitive.

Can Somebody provide the actual solution with steps?.
This needs to be deployed at the earliest .
What is the work around for this issue.

Can Somebody provide the actual solution with steps?.
This needs to be deployed at the earliest .
What is the work around for this issue.

@ryanrobinson_wlu: I was getting the bccomp error as well; I ended up fixing it by installing the 'bcmath' PHP extension. In typical docker containers, just run: docker-php-ext-install bcmath.

So after a lot of trial and error, I figured out a possible solution. I added vendor/google/** -text diff to my root .gitattributes file and also created a patch that creates a standalone id field in the database.

@jrglasgow, thank you for your solution.

Based on your suggestion, I didn't use build script, but rely on composer scaffolding capability to achieve the same thing.

my code snippet looks like below:

"extra": {
        "patchLevel": {
            "drupal/core": "-p2"
        },
        "patches-file": "composer.patches.json",
        "drupal-scaffold": {
            "locations": {
                "web-root": "docroot/"
            },
            "allowed-packages": [
                "amazeeio/drupal_integrations"
            ],
            "file-mapping": {
                "[web-root]/sites/default/all.settings.php": "assets/all.settings.php",
                "[web-root]/modules/custom/.gitkeep": "assets/gitkeep",
                "[web-root]/themes/custom/.gitkeep": "assets/gitkeep",
                "[project-root]/vendor/google/.gitattributes": "assets/google.gitattributes"
            }
        },