Missing Registrant and Registration Form Data

IzabellaDTS commented 2 years ago

A Picture Is worth a Thousand Words

Description

Occasionally, when a person submits an event registration, the registrant(s) and form data are "missing". As time has progressed more and more registrations continue to be missing this necessary information. Pictured below is a screenshot of a registrant table that has missing registrants and form data.

As you can see from the image above there are four occurrences of missing registrant info. Three of the four occurrences have some data attached to it (such as any food/medication allergies); however, one of the four occurrences is missing all the form data.

No registration should be missing this information as the majority of the questions on the form are required and a person is unable to complete the registration if any of the required questions are left blank. [See image below for partial screenshot of registration form for this event registration]

This issue has also been observed across varying Rock instances (as early as version 12.8 although seemingly more prevalent on newer Rock versions )

Steps to Reproduce

Unfortunately, this issue has yet to be reproduced. Many hypotheses as to why this error could be occurring have been tested. One such hypothesis was the user partially completing a registration and then finishing the registration a few hours later. A test was conducted and the registration behaved as expected. This along with other tests has lead us to believe that this issue occurs at random or has a cause that is not something that can be discovered through ordinary means.

Expected behavior:

When a registration is completed, any and all information from the registration is properly saved.

Actual behavior:

Most registrations save properly but, at random, some registrations are missing registrant and form data.

Versions

Rock Version: Rock McKinley 13.3 (1.13.3.1)
Client Culture Setting: en-US

leahjennings commented 2 years ago

Here's a link to a conversation in Rocket.Chat where one other user confirmed this has happened to them.

@IzabellaDTS I have just a few questions to help gather more info on this. As you mentioned, it's one of issues that is tricky and difficult to reproduce.

How many different registration templates has this occurred across?
Has it only occurred with registrations that have fees/cost attached to them?
Once an empty registrant comes through, does every registrant after that also come through empty?
Have you ran any SQL to see what value is in the PersonAliasId field on the RegistrationRegistrant table for one of the registrants that is "empty"?

IzabellaDTS commented 2 years ago

Hey Leah, Yes, that conversation in RocketChat was posted by me when I was initially investigating this issue, but to answer your questions:

1) For the particular Rock Instance pictured in the bug report, they know for a fact that it has occurred on two registration templates. However, I've seen it occur on other Rock Instances. On one such Rock instance it occurred 3 times. From what I can see it tends to happen on a handful of registration templates. 2) I have most often seen this bug on registrations with fees/costs; however, there have been a few occurrences on other Rock Instances where the registration template had no fees or costs. 3) No, this bug appears to happen at random. When a registration comes through with an empty registrant, any following registrations may or may not have a registrant. 4) I have done some SQL and for the particular Rock Instance pictured in the bug report, the PersonAliasId is not empty but instead goes to a person with no first name or last name. However, on another Rock Instance, there is no registrant tied to the registration.

To clarify a few of the findings noted above, there is a difference in what I am seeing from the Rock Instance pictured in the bug report versus other Rock Instances.

The Rock Instance pictured in the bug report has had this issue for a few months now (since before their update to v13). It appears to happen at random, but all the registration templates this bug affects does have an associated fee or cost. What is peculiar about the Rock Instance pictured in the bug report is that the registrant is missing, not empty. There is a PersonAliasId in the RegistrationRegistrant table, but that PersonAliasId goes to an anonymous person ( lacking a first name, last name, email, and phone). Further some aspects of the registration's registrant does save (some form answers come through but others don't).
However, the other Rock Instances noted above in my response to your questions are different. First, the registrants are truly empty. There is no registrant associated with the registration. This could be a bug or an Internal Rock User of that instance deleting the registrant from the registration. Some registration templates affected by this issue do have fees/costs while others don't.

I hope this helps. Thank you for your time on this matter!

Cheers!

Izabella

On Mon, Aug 1, 2022 at 8:20 AM Leah Jennings @.***> wrote:

Here's a link to a conversation https://chat.rockrms.com/channel/troubleshooting?msg=T7enJ64FWPTCEPait in Rocket.Chat where one other user confirmed this has happened to them.

@IzabellaDTS https://github.com/IzabellaDTS I have just a few questions to help gather more info on this. As you mentioned, it's one of issues that is tricky and difficult to reproduce.

How many different registration templates has this occurred across?

Has it only occurred with registrations that have fees/cost attached to them?

Once an empty registrant comes through, does every registrant after that also come through empty?

Have you ran any SQL to see what value is in the PersonAliasId field on the RegistrationRegistrant table for one of the registrants that is "empty"?

— Reply to this email directly, view it on GitHub https://github.com/SparkDevNetwork/Rock/issues/5091#issuecomment-1201195335, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUDOMZQ5XBLAHKZPDOEHK43VW7FJVANCNFSM55BYO3LQ . You are receiving this because you were mentioned.Message ID: @.***>

-- Izabella Whisenant Developer 785.813.1870 x105 Calera, AL @.*** www.dtschurch.com https://dtschurch.com https://www.facebook.com/divinetechsystems/ https://www.linkedin.com/ https://twitter.com/dtschurch https://instagram.com/dtschurch https://dtschurch.com

leahjennings commented 2 years ago

@IzabellaDTS thank you for the detailed response, this is helpful! One last question, do you know which event registration block is being used? The new Obsidian Registration Entry block or the pre-existing, regular Registration Entry block?

IzabellaDTS commented 2 years ago

I don't know for sure, but I think it is the regular pre-existing registration entry block.

On Mon, Aug 1, 2022 at 12:48 PM Leah Jennings @.***> wrote:

@IzabellaDTS https://github.com/IzabellaDTS thank you for the detailed response, this is helpful! One last question, do you know which event registration block is being used? The new Obsidian Registration Entry block or the pre-existing, regular Registration Entry block?

— Reply to this email directly, view it on GitHub https://github.com/SparkDevNetwork/Rock/issues/5091#issuecomment-1201520221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUDOMZTBKOLQE7SK5VOTGIDVXAEWZANCNFSM55BYO3LQ . You are receiving this because you were mentioned.Message ID: @.***>

-- Izabella Whisenant Developer 785.813.1870 x105 Calera, AL @.*** www.dtschurch.com https://dtschurch.com https://www.facebook.com/divinetechsystems/ https://www.linkedin.com/ https://twitter.com/dtschurch https://instagram.com/dtschurch https://dtschurch.com

azturner commented 2 years ago

We just had a church ask us about registration issue that looks like this same thing. They are on version 12.8. They are using the legacy registration entry block. The registration did have a cost.

None of the attribute values were saved (the two with values in screenshot are person attributes updated after the registration was completed).

dataCollegechurch commented 2 years ago

I would recommend parties interested continue to focus their efforts on reproducing this error. Here are some ideas I have:

One such hypothesis was the user partially completing a registration and then finishing the registration a few hours later. I think this deserves a little more testing. A few hours might not be long enough. I would minimally test 24 hours later and after the rock cache has been cleared.
I would also suggest some follow up with those submitting the registrations. Interviewing them might reveal some commonality across the various people who experience the issue. Alternatively you could review what type of device they are using and see if this error is potentially device specific.

Also for consideration. Rock is moving to the obsidian registration block long term, perhaps now is a good time to start exploring the use of that instead.

jeremyhoff commented 1 year ago

I encountered this issue moments ago using the Obsidian Registration block on Rock McKinley 14.0 (1.14.0.18).

The registration form was very simple - had only a couple of fields, one of them was a required field. A value was entered into the field for registration, but is blank "internally". I am able to reproduce this.

leahjennings commented 1 year ago

Just ran into this on our system on Rock McKinley 14.0 (1.14.0.18), using the original event registration block. It's very hit-and-miss on when this occurs. The registration where this occurred is a benevolence request entry form, and it launches a workflow that manages the approval process within our Care team. There are multiple forms in this event registration and many fields are conditional. Every single field that was a Registrant Attribute that isn't hidden by conditional was missing the information. One of the four forms in the registration surprisingly contained all the answers, and the only difference in that form was that there were no conditional fields.

There were also 3 exceptions that occurred when this registration was created, each shown here in this screenshot, although this may be related to the workflow launching on the registration. And to note, a workflow instance was not actually created.

Here's showing the registrant in edit mode:

dataCollegechurch commented 1 year ago

@azturner - should the label on this issue "Not Yet Reproduced" be removed? Or is that only removed when the Spark team has reproduced it? @jeremyhoff - would you mind listing out your steps so that we can confirm the bug is reproducible?

nairdo commented 1 year ago

I will be assigning this out to someone on our team to see if we can get to the bottom of this issue.

RufenachtPW commented 1 year ago

Mountain Christian Church is seeing this happen as well. They are on v13.7. Sometimes when it happens Family Analytics is running. Those registrations were submitted during overnight hours. That does not encompass all of the times they are like this, just some. The registration person is created/matched but the registrant is tied to a person record that contains no info. That new person is not tied to the registration persons family.

KarenRossi84 commented 1 year ago

The Crossing is on 14.2 and we have had two instances of missing registrant information on required fields in the last 11 days. We are not on the obsidian block. When testing the registration it prompts as expected if you leave these fields blank and will force you to put in information but if you look at these two registrations 6 fields are empty.

Screenshot (626)

Here is a picture of the registrant screen with the blank fields: Screenshot (628)

It does seem peculiar that some fields made it through and others didn't. In this case 5 of them were single selects and one was a text field.

IzabellaDTS commented 1 year ago

As the individual who reported this issue, I wanted to give an update.

The particular Rock Instance that prompted me to submit this issue to Spark is still facing this problem. At the time of the initial report, this Rock instance was on v13.3 and is now on v14.2.

Below I will provide an image of a registration registrant where the person came through but not any of the other required information.

Luckily, in this particular instance, we did receive the person who registered and we were able to reach out to them about their registration. The individual stated that while filling out their registration they did not complete the registration in one sitting and instead began the registration, left, and then completed the registration after some time.

To quote a previous comment on this thread

I would recommend parties interested continue to focus their efforts on reproducing this error. Here are some ideas I have:

One such hypothesis was the user partially completing a registration and then finishing the registration a few hours later. I think this deserves a little more testing. A few hours might not be long enough. I would minimally test 24 hours later and after the rock cache has been cleared ...

robotman3000 commented 1 year ago

We are experiencing the same issue on our rock instance, version 14.1 (1.14.1.1), however our situation is a little different. This is occurring using the obsidian registration block. Not sure if this should be kept here or if a new bug report should be opened. We haven't figured out how to reproduce the issue consistently.

jasonhendee commented 1 year ago

We spent some time investigating this issue; like many of you, we haven't yet been able to truly reproduce the issue in our local environment. I use the phrase "truly reproduce", because I was able to manually reproduce the issue by going out of my way to create one of the 2 most likely scenarios - detailed below - that can can lead to the outcome you're seeing: registrants with missing Person Field and Registrant Attribute values.

We understand the importance of identifying the culprit(s) for this issue, and will do our best to resolve it as soon as possible! Unfortunately, this is quite a complex area of Rock, further complicated by the dynamic nature of each registration template and its forms, as well as the hit-or-miss nature of this bug.

Observations (please correct me if you disagree):

Each of your reports above indicate that when Rock fails to save certain fields, it always happens a full form's-worth of fields at a time, often with a mix of Person Field and Registration Attribute fields being affected. I see consistent examples you've posted above - most notably your last example, @leahjennings - where the forms that were missing fields were missing ALL of the expected fields for that particular form, whether they were conditionally required or not. In Leah's last example, one of the forms did contain ALL of the expected values, whereas the other forms were all missing ALL of their values. It appears the other reported cases on this issue also follow this same pattern of "a whole form succeeds or fails at a time". @KarenRossi84, in your example, the "Share your story" field value came through, but it appears to belong to a different form than the one who's settings you gave us a screenshot of.
Forms with conditionally-required fields are affected, as well as forms without conditionally-required fields, based on the screenshots @IzabellaDTS originally shared when opening this issue.
Note that I believe this bug could also affect Person Attribute and Group Member Attribute fields if the affected form(s) were to happen to have fields of those types.

What We've Done So Far:

To further assist with identifying the true cause of this bug moving forward, we've added some exception logging in key areas of the registration code. This new logging will be in v16.0 of Rock, and will be seen as follows:

If Scenario 1 (below) is encountered, you'll see Registration TemplateForm Field Exception log entries like this:
If Scenario 2 is encountered, you'll see Registration Template Form Field Exception log entries like this:

We're Requesting Your Help:

After updating your Rock instance to v16.0 (currently in alpha testing) if you happen to see new, failed registrations that match this bug's signature, can you please post back here with some updates regarding which of the 2 scenarios you see in your exception log, if either?

More Technical Details for Those Interested

Because of the way we process registration information in both legacy (Web Forms) and new (Obsidian) Registration Entry blocks, there appear to be only two high level possibilities that can lead to the reported outcome of missing PersonField and RegistrationAttribute values:

Scenario 1 (more likely):

When saving a given Registrant, the field values for a specific form are simply not being sent back to the server. With the added complexity of conditional fields, it's even possible that we're failing to present an entire form's-worth of fields to the Registrar when they're actively registering individuals, although the latter part of this hypothesis has not been fully vetted yet.

If this scenario is encountered, we'll see exception log entries detailing which of the required, non-conditional field values were missing - per registrant - at the time of saving a RegistrationRegistrant record.

Scenario 2 (less likely):

When looping through the Registrants to save their values on the server, the RegistrationTemplateFormField collection for a specific form (RegistrationTemplateForm.Fields) has not been loaded into memory. In this scenario, even if the Registrants' collected values were sent back to the server, we don't have a form field to map each value to, so their collected values are essentially lost.

Note that this is the scenario I manually simulated in my local development environment, and as a result I saw a Registrants grid exactly like what some of you have posted screen shots of, above.

If this scenario is encountered, also note that we've added some failsafe code to load these missing form fields into memory on-demand, which should prevent the issue moving forward, while also creating an exception log so we can know we've potentially found the issue that led to past failures:

dataCollegechurch commented 1 year ago

@jasonhendee - Do either of the two scenarios explain the infrequent nature of the bug or why this might be occurring on some people's instances and not others? Also does the team have a sense of what could cause the system to fail to present an entire form's-worth of fields or fail to load fields into memory?

jasonhendee commented 1 year ago

@dataCollegechurch,

Do either of the two scenarios explain the infrequent nature of the bug or why this might be occurring on some people's instances and not others?

These scenarios directly explain neither, but were provided to 1) indicate that we are actively working on this issue and 2) explain the newly-introduced exception logging made visible in the timeline of this issue's comment thread, by way of the commits I made a few days ago.

Also does the team have a sense of what could cause the system to fail to present an entire form's-worth of fields

This is a hypothesis I have, but haven't yet had a chance to fully vet; it's in no way been proven to occur. I admittedly posted that a little prematurely, and should have been a bit more sure before mentioning it. Something is apparently causing the process to sometimes miss a form's-worth of fields at a time, so I want to spend more time in this area of the registration entry's code to ensure it's operating as designed.

or fail to load fields into memory?

This could be related to something called View State on the Legacy Web Forms side or could be related to something called lazy loading on the Obsidian side. Either way, the commit above will address this if it was the culprit, by ensuring the fields are loaded on-demand, as needed.

I took more of an inside-out approach to attempting to uncover the true cause of the issue, and haven't found it yet, but will continue to dig as time allows. Thank you for your patience, and I truly appreciate your comments and questions throughout this thread!

dataCollegechurch commented 1 year ago

@jasonhendee - thanks for the feedback and your hard work on this, curious to see how this one pans out.

dataCollegechurch commented 11 months ago

I wonder if we can add some sort of tracking that shows when someone starts a registration. That could help with troubleshooting around issues arising from registration pages kept open for a long time. Perhaps the start time for a registration could show up in the Registration Audit Log.

cabal95 commented 11 months ago

If anybody runs into this again (or has recently) and would like to run this SQL (after filling in the registration id on the first line) and post a screenshot of the results (feel free to blur out any values you need to, the big thing will be to know if the NewValue for the Property change types are null when first created). This should help narrow down if the issue is truly when the registration is created or if the data is somehow getting blanked out after it is created.

DECLARE @RegistrationId INT = 0

SELECT
    [Caption]
    , [Verb]
    , [ChangeType]
    , [ValueName]
    , [NewValue]
    , [OldValue]
    , [CreatedDateTime]
    , [CreatedByPersonAliasId]
FROM [History] AS [H]
INNER JOIN [EntityType] AS [ET] ON [ET].[Id] = [H].[EntityTypeId]
WHERE [ET].[Name] = 'Rock.Model.Registration'
  AND [H].[EntityId] = @RegistrationId

leahjennings commented 11 months ago

@cabal95 I ran the following SQL to find any Registrants with empty first/last names to get the Registrations affected:

  SELECT rr.RegistrationId, p.FirstName, p.LastName, rr.CreatedDateTime
  FROM RegistrationRegistrant rr
    JOIN PersonAlias pa ON (rr.PersonAliasId = pa.Id)
    JOIN Person p ON (pa.PersonId = p.Id)
 WHERE p.FirstName = ''
   AND p.LastName = ''

The most recent one we had (preserved in our development instance) was August 2023. Here's the results of the SQL you posted:

With this Registration Template, we have two forms. Information from neither of them got recorded. The first form asks for some of their personal info (all Person Field type), and the second form is all specific info related to what they are registering for. Form 1:

Form 2:

cabal95 commented 11 months ago

@leahjennings Are you able to confirm if, when looking at the Registrant in the UI, that the person shows up without a first and last name?

I want to confirm that the history data does indeed show that it set the First and Last name - but that now when you look in the UI those values are blank.

leahjennings commented 11 months ago

@cabal95 correct. The name listed in the screenshot of SQL results is the registrar. Registrar gets set correctly, the Registrant however is blank.

When we've caught this and corrected it, I have to merge the empty profile (which is attached to the registrant) with the profile of whoever it should've merged with (typically the registrar).

leahjennings commented 11 months ago

And looking at the empty profile's history, the first/last name fields never get set:

cabal95 commented 11 months ago

Thanks @leahjennings, I'll do some additional digging with that data!

cabal95 commented 11 months ago

Hello everybody, wanted to give everybody an update on where we are at with this.

Based on the information Leah was able to provide from the History table (and various local experiments on ways the exact same thing could happen), it seems clear that the core issue is happening on initial save. Meaning, it isn't a problem of some process running after the registration is created that is somehow erasing the data. The history table should contain a row for every single property that is filled in on a Registrant. Since it is essentially empty (other than the data about the registration itself) we feel that is a pretty clear indication that somehow the data is not making it there in the first place.

As Jason pointed out previously, we can't find anything in the code that would cause this to happen. Essentially, part of the registration data (number of registrants, the registrar information, discount details, etc.) is making it to the "Save" logic. But other parts of the data (the details entered about the individual registrants) is not. From looking at code, stepping through it, and trying various things to intentionally break it, it just doesn't make sense that this would happen.

Another option is that the field data is making it to the "Save" logic, but somehow all the details from the Registration Template that describes the fields are somehow missing so it can't actually do anything with those fields. Again, this doesn't make sense because it would have to be only part of the template data missing - again specifically the form field information. If other parts of the template data are missing, an exception gets thrown and displayed to the user and nothing is saved.

Basically, the problem seems to be one of those things where probably many things have to align properly, even possibly down to something like a registration being completed as the Rock server is in the process of restarting or something bizarre like that. (We even tried to replicate the bug by doing that a few dozen times)

The plan

First: In addition to the changes Jason already made to add logging whenever something like this is encountered (as best we can tell anyway), we have also added some additional logic in Rock 15.3. If the "First Name" or "Last Name" are missing from any Registrant, than the entire registration will be blocked and an error will be displayed to the end-user. No registration information should be saved.

While this may not catch every single instance of this happening, from looking at the data it does seem like it will catch the majority of them. If you have a multi-form registration and the data on the first form comes through but the data on the second form does not, you might still get those slipping through. First and Last name are easy to get to and verify because they are essentially hard-coded into all registrations. all the other fields get to be more complex and run into issues of the "empty check" code being skipped entirely if the field is somehow missing from the registration template too.

Second: We don't believe this same issue is occurring in Obsidian. There were two reports (one on 14.0 and the other on 14.1) of this happening with the Obsidian block, and one of those specifically said the issue they were seeing was slightly different. In addition, we have fixed many bugs on the Obsidian side - some specifically around data showing up null on the internal page related to certain types of form fields - since then. To that end, we believe the two mentions of Obsidian were probably not the same exact issue as the one being discussed here.

Therefore, the long term solution would be to move to the Obsidian Event Registration block. Rock 15.3 and 16.1 should have nearly all the recent fixes for bugs regarding Obsidian Event Registration.

Finally: We plan to close this issue in a week or two. This does not mean we don't care or are not willing to look into this again if more details become available. Such as somebody finding a way to reproduce this on their server. We really appreciate all the details and screenshots everybody here has provided. What it does mean is that we have a number a mitigation checks in place that should hopefully reduce or possible entirely prevent this from happening in the future. And the new Obsidian block should not have this same bug.

Below you can see a sample of what the new First Name and Last Name check will look like:

jsw-austin commented 11 months ago

@cabal95 ++ for a thorough explanation. Appreciate the detail here.

stanalyst commented 6 months ago

We just upgraded from v14.3 to v16.2 last week - and have started to see the new exceptions put in by Jason. In our case they all appear to be scenario #1.

Here's the list of 5 we received in the past 3 days...

Setup for 1 of the 2 Registrant attributes...

Here are the details for the 1 exception entry that was for a Person Field (Birthdate).

Running the SQL from above ... noticed that Birthdate isn't listed at all.

Here is the setup of the registration form that included the Birthdate...

nairdo commented 6 months ago

@stanalyst Thank you for that data. Are you using the original (webforms) Registration Entry block or the newer Registration Entry (Obsidian). The Obsidian version has that different progress bar as seen in this screenshot:

stanalyst commented 6 months ago

we are on the webforms version of the block

nateh777 commented 6 months ago

We have a client experiencing these exceptions with 15.4 using the Obsidian Registration Entry, but not as serious repercussions as the OP. It seems like the fields are getting saved just fine with the initial registration. However, if it is a registration that you make payments on, when they come back in and "edit"/review the registration and make a payment, that is where their exceptions come from. I have not verified it with an exact scenario test yet on a demo server but looking at their exception log and matching it to the registration/registration history, the time of the exception is exactly when they make an additional payment.

Hoping this will add something to this issue research, if not no worries, I can at least explain where it is coming from.

dataCollegechurch commented 6 months ago

@nateh777 - Did the data in the mentioned fields for individual 50268 also get deleted as a result of submitting the payment?

nateh777 commented 6 months ago

@dataCollegechurch no, the data did not get deleted, just generated the exception, I think it was a false exception more than anything for my scenario, just wanted to point it out.

markburlesoncrds commented 5 months ago

the issue is still occurring in the Obsidian Reg Entry block. Carl has further details. Please reopen the issue. Thanks!

chead4 commented 5 months ago

@markburlesoncrds Hi Mark - thanks for reaching out and letting us know that this issue is still occurring on the Obsidian Registration Entry block. I will reopen the issue and reach out to Carl to get more details.

nlBayside commented 1 month ago

We've been seeing this appear in some of our Registrations too recently for summer camp. When I looked at it, my first thought was "Oh it's a required form field, but it's internal". I tested this on the demo site with a generic Registration Instance without fees/cost, and was able to generate the exception.

Images

The Form Fields on the Registration Template

Successful Registration without entering the internal field

Results from one of the above SQL queries that checks the History table.

Exception generated on SubmitRegistration

In the Registration Templates on our end we had a Person attribute that was marked Internal, Use Current Value, and Required. The Registrant's Person had the Attribute on their profile, but it still generated the exception (probably because they didn't enter it in the form itself). I don't think we've had any issues where a whole Form saved as blank. The question in our Registration Template also wasn't conditional.

The test was done on the demo site with a new Person (Test Person). The test person doesn't have the Allergy Attribute I used in the Form, but they also aren't prompted for it since it's internal.

(This doesn't necessarily look like it's a problem for us btw. As in, the exception probably doesn't need to be generated when its internal, use current value, and required if the Person already has that Attribute) Hopefully this helps a little bit with getting to the bottom of this problem!

SparkDevNetwork / Rock