Known Issues (2.3.4)
In
2.3.4, there are the following known issues:HTTP Error 500 Server Error Encountered After Upgrade from version 2.3.2
A known issue prevents a direct upgrade from version 2.3.2. If this is done a HTTP Error 500 Server Error will be produced in the mzdesktop package. To mitigate this, the upgrade path from 2.3.2 is to update to 2.3.3. and then to 2.3.4.
mzcli Commands Do Not Provide Return Codes
If you are using scripted solutions requiring return codes, you must use the mzsh commands, since the mzcli commands do not provide return codes.
OpenAPI Validation Error for Type enum
There is a bug when performing OpenAPI validation for parameters of the enum type. The bug is based on: https://bitbucket.org/atlassian/swagger-request-validator/issues/161/mockmvc-openapi-30-type-of-enum-parameter
The error is recorded as:
Error(s) during request validation: Unable to parse JSON - Unrecognized token'xxx': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false')
This occurs when you send a request to an NRF server that is configured using our HTTP2 Server agent with OpenAPI validation enabled. You will be meet with a Bad Request error (Error 400) and the validation fails. There was an issue with the specifications for the type enum within the 'anyOf' section as seen from the example below.
Example: NFType found in TS29510_Nnrf_NFManagement.yaml
NFType: description: NF types known to NRF anyOf: - type: string enum: - NRF - UDM - AMF - SMF - AUSF - NEF - PCF - SMSF - NSSF - UDR - LMF - GMLC - 5G_EIR - SEPP - UPF - N3IWF - AF - UDSF - BSF - CHF - NWDAF - PCSCF - CBCF - HSS - UCMF - SOR_AF - SPAF - MME - SCSAS - SCEF - SCP - type: string
A workaround would be to add the 'type: string' parameter on the same level as the 'anyOf'.
Encrypted Dynamic Workflows Uneditable in Web Interface
It is recommended not to use or create an encrypted dynamic workflow as you will not able to make any changes to the workflow in the web interface.
Importing Old Configurations with Web Services Using Keystore Requires Additional Configuration
If you have an old webservice configuration from 8.x that uses keystore then the existing Security profile will be empty and to use a Security profile, you need to create a new one. This also applies to Diameter if it uses the Security profile.
The mzcli Command 'disconnect' is not Working on Containerized Solutions
When running the disconnect (2.3) command in a containerized solution the ECD will unexpectedly terminate.
Terraform template does not support M1 Mac with darwin_arm64 architecture
The setup files for AWS installation does not contain a provider that supports the new M1 Mac darwin_arm64 architecture.
The error is recorded as:
➜ terraform terraform init Initializing the backend... Initializing provider plugins... Finding hashicorp/aws versions matching "~> 2.0"... ╷ │ Warning: Version constraints inside provider configuration blocks are deprecated │ │ on provider.tf line 5, in provider "aws": │ 5: version = "~> 2.0" │ │ Terraform 0.13 and earlier allowed provider version constraints inside the provider configuration block, but that is now deprecated and will be removed in a future version of │ Terraform. To silence this warning, move the provider version constraint into the required_providers block. ╵ ╷ │ Error: Incompatible provider version │ │ Provider registry.terraform.io/hashicorp/aws v2.70.1 does not have a package available for your current platform, darwin_arm64. │ │ Provider releases are separate from Terraform CLI releases, so not all providers are available for all platforms. Other versions of this provider may have different platforms │ supported.
Known Vulnerability CVE-2019-10797 when Using Netty 3
When using Netty 3 there is a known vulnerability (CVE-2019-10797 according to NIST) and the solution and workaround is to use Netty 4.
In other words, the known vulnerability (CVE-2019-10797) does not affect you if you are using Netty 4.
To be backward compliant in terms of performance requirements, it is not feasible to remove Netty 3 from MediationZone at this point.
Importing Old Data Veracity Collection Agent Workflow Configurations Returned Validation Errors
If you have an old Data Veracity Collection Agent Workflow configuration from version 8.x, it is possible that validation errors about invalid Analysis Agents may occur.
Example error during import:
The following agents returned validation errors. Analysis_1 is invalid. The UDR type DataVeracityUDR (DataVeracity) doesn't exist
Example error when viewing the invalid workflow Analysis Agent configuration:
Error: Failed to set UDR Types Message: Unable to create UDR type description from DataVeracityUDR (DataVeracity).
To resolve this, you will need to re-add the Data Veracity UDR for Analysis Agent input UDR Types or use the Set To Input button if applicable. After adding the appropriate Analysis UDR Types, save the workflow configuration.
Open API Profile Schemas that Require a UDR Must Be Named
All schemas that require a UDR must be named. Due to a limitation in the third party parsing library used by OpenAPI, unnamed schemas cannot be detected and will not generate a corresponding UDR. Therefore, you must name all schemas that require a UDR. For more information, see Open API Profile.
UDR Configurations Removed in HTTP/2 Server Agent
If you are importing workflows from to , it is possible that errors may occur. Once the workflow is imported, the configurations in UDR Type field in HTTP/2 Server agent will be cleared and users are then required to manually reconfigure the UDRs.
This will be fixed in a future release.
OpenAPI Configurations Removed in HTTP/2 Client Agent
If you are importing workflows from to , it is possible that errors may occur. Once the workflow is imported, the configurations in OpenAPI tab in HTTP/2 Client agent will be cleared and users are then required to manually reconfigure them.
This will be fixed in a future release.