-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forms migration not updating form 10-334 #18898
Comments
We do have evidence that the Migration is making CMS migrator revision logs on other nodes: |
Daniel still digging, we can't reproduce the problem so far. |
Summary of Findings: Drupal Migration Bug InvestigationOverviewOver the past few days, I have been investigating a potential bug in the VA Forms migration process. The bug is related to detecting changes in CSV files fetched over HTTP, specifically those that contain form data with a revision_date field change. The issue was originally noted in the production environment, but I was unable to reproduce the problem locally or in Tugboat. Key FindingsHTTP Fetch Consistency: The migration process reliably fetched the updated CSV files over HTTP, and changes to the revision_date, issue_date, and title fields were reflected in both environments. This suggests that the HTTP data fetcher is functioning as expected in both environments. Cache Behavior: I initially suspected a caching issue in production, where the migration might be pulling cached versions of the CSV file, preventing updates from being applied. However, after clearing caches, resetting migration statuses, and closely monitoring cache behavior, I ruled this out as the cause. Migration Map Tables: The migration map tables (stored in the migrate_map_* tables) store state information about previously processed rows, which prevents Drupal from reprocessing unchanged data. These tables were correctly reset during testing, and data was consistently updated when triggered by upstream changes. Reproducibility: Despite extensive testing, I could not reproduce the bug locally. All changes to the CSV file, including revision_date, were detected without issue when testing in my local environment. Issue DescriptionThe migration process is intended to update VA Forms in Drupal whenever changes are made to upstream Forms Database CSV files, which are fetched from a remote URL using the http data fetcher. The focus was on changes in the revision_date field, which should trigger updates to the associated content in Drupal, though there are other fields that should do this as well including but not limited to the issue_date and title. Modifications to the revision_date and other fields in the upstream Form database CSVs, Drupal's migration did not consistently reflect those updates in production. However, when I replicated the environment locally, the migration process worked as expected, detecting and applying changes to the revision_date field without issue. Environment DetailsProduction Environment: The bug was observed in the live environment where the CSVs are hosted on an local filesystem, but the files are still fetched over an HTTP server. The data is fetched using Drupal's url source plugin and the http data fetcher from Migrate Plus. Local Environment: When replicating the production setup locally, the migration consistently detected changes in the CSV file, including updates to the revision_date field. Potential CausesWhile I was not able to fully reproduce the issue locally, there are a few potential causes that could explain the inconsistency: Environment-Specific Factors: The issue could be tied to environmental differences between production and other environments, such as file system caching, network latency, or configuration differences in server settings. Intermittent Connectivity Issues: In the production environment, temporary connectivity issues between the HTTP server hosting the CSV and the Drupal instance could result in failed updates, but this would not consistently explain the behavior. File Integrity: There could be differences in file integrity between what is fetched locally and what is fetched in production, though no concrete evidence of this was observed during testing. Resolution StepsNetwork and Server Checks: Investigate any network or server configuration issues that may prevent proper fetching or caching in production. Continue monitoring the migration process in production and compare logs with the local environment to pinpoint any subtle differences. If the issue persists, consider setting up a staging environment more closely mirroring production to try to reproduce the issue under more controlled conditions. ConclusionWhile the exact cause of the bug in the production environment remains elusive, my investigation ruled out several potential issues, including caching, Drupal migration processing logic, and fetching inconsistencies if the problem is persistent/pervasive. Further investigation is required to determine whether environment-specific factors are contributing to the problem which would itself require someone on the CMS team to be involved. AppendixOverwrite Properties - Fields that when updated overwrite existing Drupal field data. These fields are: |
These notes are excellent, thanks so much for showing your work. Sounds like we might end up hitting up the CMS team for info on devops / env stuff -- holler if you need any support, if you go that route. |
BLUF: We can't repro the bug, and should close this as can't repro. But: we can opt to add some logging or do some stakeholder outreach with Forms Managers to rule out a more system issue, short term. Notes below that need a product call. cc @FranECross @mmiddaugh for product input. From 1:1 with @dsasser :
Some ideas about what to do next:
Either of those should likely be a new ticket, depending on how we want to approach it. Leaving this ticket open til we get a chance to discuss / decide if we'll follow up in a new ticket. |
@jilladams @dsasser Let's go with #1 for now. Closing ticket and |
User Story or Problem Statement
July 18 we identified that Form 10-334 was displaying a future "Form updated" date on VA.gov: April 2028
CMS data
Form node: https://prod.cms.va.gov/find-forms/about-form-10-334
Revision date: April 2028
Revision logs: no recent revision logs from the CMS migrator
CMS screenshot showing Forms DB data with future revision date
Front end
FE page: https://www.va.gov/find-forms/about-form-10-334/
FE screenshot
Data updates / migration
On July 31, the VHA forms manager said they had updated the future date in the Forms DB for both the internet and intranet.
When I checked the page on 8/9, the future date still appears and the node still doesn't show any CMS migrator activity.
However, the Forms migration from 8/9 shows a Revision date for this form of Apr-23 (4/1/2023).
va_forms_data (8).csv
I don't know what the
InstallationDate
field means in the migration (field map says "Sometimes corresponds to issue_date (2016-09-20 08:07:10"), but it's timestamped7/30/2024 2:31:10 PM
, which is about the timeframe that the Forms manager said they'd updated the Forms DB for the internet (vs. intranet which came later but we don't really care about).The mystery: why doesn't this revision date update appear on the CMS form node?
Acceptance Criteria
The text was updated successfully, but these errors were encountered: